Git commit message 관리

Git commit message 관리 (with. rebase)

git을 작업 이력을 저장하는 용도로만 사용하다보니 commit 이력이 지저분해지기 시작했고 코드리뷰가 어려워지기 시작했다. 또한, 특정 시점으로 코드를 rollback 하려고 했더니… 내가 원하던 시점을 도무지 찾을 수가 없었다.

 

아, 그리고 하나 더 말하자면 release 배포 후 release note를 자동 불러오기 했을때 특정 기능을 개발하는동안 올려두었던 commit message들도 죄다 올라와서 어떤 기능이 추가됐고 변경되었는지 알아보기 어려웠다.

 

이런 이유들로, Git commit message 관리가 필요하다고 느꼈다.

 

 

1. 최소한의 메시지 작성 규칙

 

1) 소스코드를 보지 않고 커밋 메시지만으로 어떤 변경사항이 있었는지 알 수 있도록 하기
ex) Credit 모델에 use 메소드 추가 - O,  use 메소드 추가 - X

2) 제목에 자세한 내용을 담기 어렵다면 커밋 메시지 본문에 “왜”, “무엇을”, “어떻게” 변경했는지에 대한 상세한 내용 설명하기
ex)
Credit 모델에 use 메소드 추가

새 속성 값이 필요하기 때문에 namedtuple에서 클래스로 전환했다.

 

3) 작업 내용을 정확히 알 수 없는 추상적인 메시지 사용 금지
CSS 수정, 코드 정리, 작업중 등

 

4) 일정한 언어 사용하기
영어던 한글이던 하나만 정해서 사용하는것이 바람직하다.

5) Semantic Commit Messages를 사용해서 어떤 작업 유형인지 구분하기 https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

 

---

 

2. 특정 작업이 완료 된 후 메시지를 정리하자 (with. Rebase)

프로젝트가 성장할수록 한 프로젝트를 함께 개발하는 개발자가 많아지게 된다. 이때 적절히 git의 기능인 rebase를 사용한다면 커밋 메시지를 좀 더 효율적으로 관리할 수 있다.

아래 그림과 같이 master(base) 브랜치에서 파생된 두 개의 브랜치 issue2와 issue3이 rebase를 사용하면 하나의 라인으로 작업내용을 순차적으로 기록할 수 있다.

아래 그림과 같은 상황이 있다고 해보자.

 

1. base 브랜치인 main 브랜치에서 개발자들은 각자 맡은 업무에 해당하는 feature 브랜치를 생성하게 된다.
feature/sum 브랜치와 feature/multiple 브랜치가 생성되었다.

 

2. 개발자들은 각자 개발을 하고 main 브랜치에 머지를 하게 되는데 (현업에서는 PR을 통해 머지하는것이 일반적이다)

 

3. merge를 통해서만 branch를 합칠 경우 커밋 히스토리가 복잡하게 섞여 보이게 된다.

4. rebase를 통해 branch를 합칠 경우 하나의 라인으로 순차적으로 작업 내용이 정리된다.

테스트

# 1. feature/sum 브랜치 먼저 main으로 merge
$ git checkout main
$ git merge feature/sum

 

# 2. feature/multiple 브랜치에서 main 브랜치 rebase
$ git checkout feature/multiple
$ git rebase main

 

# 3. main 브랜치에서 feature/multiple 브랜치 merge
$ git checkout main
$ git merge feature/multiple

 

# merge만 사용하여 두 개의 브랜치를 합친 경우
$ git checkout main
$ git merge feature/sum
$ git merge feature/multiple

 

모두 즐거운 코딩하세요~