개발자로 협업할 때 Git을 사용하는 것은 아무리 잘써도 부족하지가 않은데, 최근에 이에 관련하여 좋은 조언들을 많이 얻었고 스스로 복기하고자 한다.
항상 Best Practice일 수는 없지만, Worst Practice는 최소한 피해보자는 마음에 해당 글을 작성해본다.
Git Commit
커밋 메세지 작성하기
- 커밋의 단위는 최대한 작은 작업 단위로
- 한번에 몰아서 하는 대신에 여러번 자주
- 커밋 메세지는 남들에게 보여주는 규칙이다
One Line Comment
``` line feed ```
Detailed Description
- 위와 같은 구조가 되면 좋은데, 예를 들면 이런 식이다
Refactor A module to fix B error
This commit is dealing with issue #123.
- 혹여나 내가 현재 브랜치에서 만든 커밋이 너무 작거나 의미없어도 괜찮다. 우리에겐 수정의 기회가 있다(REBASE!)
- 우리는 보통 글을 작성할 때 나 혼자만 읽는 것이 아니라 남을 설득하고 이해시키는 글을 쓰려고 해보자
- 남을 설득시키는 글이란 뭘까? 항상 결론이 먼저 나오면 좋다. 남들은 절대로 내 글을 전부 읽으려고 하지 않는다
- 커밋 메세지를 잘 써야하는 이유는, 결국 남에게 내 코드를 이해시키고 유지보수하는 데 드는 비용을 줄이기 위함이다
Git Branch
브랜치 관리하기
- 기본적으로 브랜치 관리는 조직, 기관마다 정책이 다르다. 자신이 속한 기관에서 확립된 정책이 있다면 그것을 따르면 된다
- master라는 브랜치 이름은 이제 사용하지 않는다
- 개발은 develop에서, 배포는 main에서
- 네이밍 컨벤션: 일반적으로는 {카테고리}/{설명} 을 많이 사용한다
- Bug Fix
- Hot Fix
- Feature Branches
- Experimental Branches
- WIP branches
- upstream, origin, local 구분하기
- upstream은 모두가 공유하는 원격저장소를 의미한다. 이 저장소는 맘대로 수정되어서는 안된다. 하나의 PR을 만들 때 리뷰의 과정을 거쳐서 붙여져야 한다
- origin은 나만 사용하는 fork된 원격저장소를 의미한다. 이 저장소에서는 내가 작업한 내용을 입맛대로 붙이고, 미친 실험들을 해볼 수 있다
- local은 내 로컬 리눅스 머신을 의미한다. 실제 작업을 하는 컴퓨터 환경이다
- upstream과 origin의 develop 브랜치 헤드 맞추기
- 위 사진처럼 origin과 upstream의 개발 브랜치의 헤드 위치를 항상 맞춰놓아야 한다. 만약 맞지 않다면, 병합을 하고 개발하자
Git Merge
브랜치 병합하기
- 위에서 설명한 분기된 브랜치들을 병합해주어야 한다
- 병합하는 시점은 짧으면 짧을수록 좋다
- 서로 시작하는 분기점에서 멀어질수록 충돌이 생길 가능성은 높아지고, 병합은 더 어려워진다
- 일반적으로 Github에서는 세가지 PR의 병합을 제공한다
- Squash and merge: 병합 커밋 하나에 PR에 달려있는 커밋들을 밀어넣는다.
- Merge commit: 병합 커밋을 새로 만들고, 브랜치를 이어붙인다.
- Rebase and merge: PR에 달려있는 커밋들을 베이스 브랜치에 리베이스하고 추가한다.
Git Rebase
브랜치 리베이스
- 말그대로 베이스를 옮기는 과정이 리베이스
- 리베이스 명령으로 커밋의 베이스를 옮기면서 커밋들을 한번 정리할 수 있다
$ git rebase -i [브랜치명]
- 이후 pick/edit/squash/fixup 등 명령으로 정리되지 않은 커밋들을 한번 정리할 수 있다
Git Cherrypick
커밋 체리피킹
- 체리피킹이란 말그대로 다른 브랜치에 있는 특정 커밋을 내 브랜치로 가져오는 것이다
$ git cherry-pick [커밋해쉬]
- 사실 개인적으로 이 기능을 현업에서 사용하는 것을 본 것은 딱 한번이다
- 다양한 버전의 릴리즈를 하나 동일한 코드베이스를 가지는 저장소에서 요구사항에 따라 사양이 급하게 바뀌었을 때 사용이 용이한듯 하다
마치며
여러가지 잘 알려진 개발 원칙들이 있지만 제일 중요한 것은 사람들간 소통인 것 같다.
개발은 다른 사람과의 커뮤니케이션이기 때문에 불변의 원칙은 있을 수 없다고 생각한다.
