(번역) Six Rules for Good Git Hygiene

March 06, 2020

Medium 에서 좋은 글 Six Rules for Good Git Hygiene이 있어서 내용을 간단하게 정리해본다.

feature image

항상 Push 하기 전에는 pull 할 것

이것은 매우 근본적인 규칙이다. 레포지토리에 코드를 push 하기 전에는 항상 리모트 레포지토리의 모든 현재 변경을 모두 로컬 머신에 pull 해야 한다. 그렇게 하는 것이 로컬 카피가 리모트 레포지토리와 sync가 맞는 것을 보장할 수 있다. 다른 사람들이 리모트 copy에 계속 push를 해왔기 때문에 sync 하지 않고 만약 Push를 한다면 결국 multiple heads 혹은 push 할 때 merge conflict 이 발생할 것이라는 명심하라.

Pull 은 자주 할 것

많은 팀원들이 작업할 때 중앙 레포지토리는 꾸준히 변경이 된다. 가능하면 로컬 머신을 리모트 레포지토리와 변경 사항이 적도록 유지해야한다. 이를 위한 방법은 리모트 서버의 모든 변경 사항을 로컬 copy 에 pull 하는 것이다. 이 작업은 당신이 원하는 만큼 자주 수행할 수 있고 그래야만 한다. 적어도 하루에 한 번은 해야 합니다.

Push 는 가끔 할 것

당신이 push 하게 되면 당신의 당신의 변경 사항을 남들에게 안겨주게 됩니다. 이는 당신이 빌드를 깨지 않을 것을 알때. 당신이 push하고 있는 것이 무엇인지 잘 리뷰했을 때. 당신의 로컬 코드가 다른 사람에게 유용하게 될 상태라는 것을 느낄때에만 push 해야 합니다.

명심하십시오. 당신이 push 했을 때 모든 사람이 당신이 한 것을 보게될 것입니다. 맞는지 확인하세요.

Commit 은 자주 할 것

많은 개발자가 충분히 자주 commit 하지 않습니다. 따라서 결국 많은 변경을 한 이후에 commit 을 하게 되어 결과적으로 이들에 대한 comment 가 그 많은 변경을 설명하기에는 턱없이 부족하게 됩니다. 많고, 많은 commit 들을 리뷰하는 것은 짜증나고, 비생산적입니다.

대신에 작고, 하나의 변경 사항을 자주 commit 해야하고, 이 commit 에는 이 작고, 구분된 변화에 대해서 주의깊게 잘 설명하고 있는 commit message를 작성해야 합니다. 쉽게 이해할 수 있는 commit 이 많은 것은 잘못된 것이 아닙니다. 만약 commit message 에 “그리고”, “~와 함께” 단어를 사용해야한다고 느낀다면 당신은 아마도 충분히 자주 commit 하지 않고 있는 상황입니다. 작은 commit 은 이해하기 쉬고, 필요한 경우에 revert 하기도 훨씬 쉽습니다.

자주 merge forward 할 것

당신이 일반적인 git workflow를 사용한다고 가능하면, 당신은 개발 브랜치에 기반을 하고 있는 브랜치에서 대부분의 시간을 보내게 될 것입니다. 당신의 브랜치가 어디에서 땄건 간에 당신은 주기적으로 오리지널 브랜치를 당신 브랜치에 머지해야 한다.

그렇게 함으로써 당신이 작업하는 브랜치가 오리지널 브랜치에서 너무 많이 분기하지 않도록 보장하여 줍니다. 명심하십시오. 다른 사람들도 또한 오리지널 브랜치를 변경시킬 것입니다. 이렇게 함으로써 당신은 merge conflict를 줄이고, 더 쉽게 개발할 수 있도록 해줄 것입니다.

Pull Request 는 드물게 생성할 것

원하는 만큼 “앞으로”를 병합할 수 있지만 코드를 다시 개발 분기로 병합하기 위한 풀 요청을 만드는 데는 훨씬 더 신중해야 한다.

당신의 조직은 아마도 pull request에 대한 정책을 가지고 있겠지만 pull request 를 보내는데에는 주의를 기울여야 합니다. Pull request는 다른 사람에게 당신의 코드를 매우 자세하게 살펴봐달라고 요청하는 것이므로 주의를 가지고 해야 합니다. 코드 베이스에 명확하고 개별적이며 완전하게 추가될 수 있는 상태에 있는 경우에만 pull request를 요청 해야 합니다. 다시 한 번 “그리고”, “~와 함께” 단어를 사용하고 싶은 생각이 든다면 아마도 pull request 가 너무 큰 경우입니다.

Pull request는 드물게, 주위 깊게 생성해야 합니다.

댓글 반대 의견

댓글에 주기적으로 pull 하라는 것에 반대 의견이 있어서 같이 적어봅니다.

실용적인 경험으로 볼때 자주 pull 하라는 의견에 반대합니다. 제가 있었던 조직은 꽤많은 버그가 Push 되고, 다음날 이들에 대한 수정이 반영되는 조직에서 개발을 하였습니다. 가장 좋은 방법은 브랜치에서 작업을 완료하고(단위 테스트로 포함) Pull request/push 준비가 되었을 때에만 유효성이 확인된 릴리스를 당겨 최근의 변경으로 코드 컴파일/유닛 테스트가 중단되는지 점검하는 것이었습니다.


By @tkhwang: 🌱 I want to DEVELOP something FUN and USEFUL.