[Git] 깃 커밋 메시지 작성법(git commit message) - 1

이름을 짓는다는 것

네이밍의 어려움은 프로그래밍을 하다보면 자연스래 느끼게 될 부분이라고 본다

변수, 클래스, 함수의 네이밍.... 해도해도 감이 잘 안 잡히고 너무나 어려운것...

이것에 아무런 고충이 없고 바로바로 생각이 난다면 업종을 바꿔서 작명소를 하는 것도 괜찮을거 같다

 

깃을 사용하는 데에 있어서도 이같은 문제와 직면하게 되는데 바로 Commit message이다

심지어 문장이라 어떻게 써야 할지 더 막막하다

한글로 커밋 메시지를 작성한다면 그 고충은 덜 하겠지만 영문으로 작성한다면 정말 답답할 것인데

최대한 규칙에 맞는 커밋 메시지를 작성하도록 계속 발전하기 위에 작성법에 대하여 적어본다

 

---

커밋 메시지란?

working dir(작업중인 로컬 디렉터리)에서 git add를 하게되면 변경된 파일의 목록이 index(stage)에 추가가 되는데 이 파일의 목록들을 HEAD(확정본)에 반영을 시킬 때 git commit을 쓰게 된다

commit message는 쉽게 말하면 HEAD에 어떤 변화가 반영이 되었는지 설명하기 위한 글이다

 

 

규칙에 맞는 좋은 커밋메시지를 작성해야 하는 이유는?

• 팀원과의 소통
• 편리한 과거의 기록 추적

 

 

Commit Options

• -m

커밋 메시지를 작성

git add file
git commit -m "FIX 블라블라"

 

• -a or --all

모든 파일을 자동으로 Commit(될 수 있으면 쓰지 않는 것을 추천)

git commit -a -m "ADD 블라블라"

 

• --amend

원격 저장소로 푸쉬되지 않은 마지막 커밋 메시지를 다시 작성

git add .

git commit --amend -m "ADD 블라블라블라"

 

 

좋은 커밋 메시지 작성법

좋은 커밋 메시지를 작성하기 위해 사용하는 몇 가지 규칙에 대하여 알아보도록 하자

 

1. 커밋 유형 지정

• FEAT : 새로운 기능의 추가
• FIX: 버그 수정
• DOCS: 문서 수정
• STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
• REFACTOR: 코드 리펙토링
• TEST: 테스트 코트, 리펙토링 테스트 코드 추가
• CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)

 

2. 제목과 본문을 빈 행으로 분리

   여러 행으로 구성된 커밋 로그를 -m 스위치를 사용해서 입력하기는 어렵다 적합한 편집기를 사용하여 편집을 진행하     여야 하는데(깃 커밋 에디터 사용법) 해당 글을 참고하자

 

3. 제목 행을 50자로 제한

  강제로 제한하는 것은 아니고 읽기 쉽고 간결하게 표현하기 위한 경험에 의한 규칙이다

 

4. 제목 행의 첫 글자는 대문자로 시작

• readme file modification X
• Readme file modification O

5. 제목 행 끝에 마침표를 넣지 않는다

제목 행의 끝에는 마침표가 필요 없다. 50자 규칙에 따르기 위해서라도 마침표를 넣는 것은 불필요한 공간 낭비이다

• Open the door. X
• Open the door O

6. 제목 행에 명령문을 사용한다

 "명령이나 설명하듯이 작성"

• 네 방을 치운다 (Clean your room)
• 문을 닫는다 (Close the door)
• 쓰레기를 갖다 버린다 (Take out the trash)

7. 본문은 72자마다 끊어 줄을 바꿔준다.

8. 본문을 사용하여 변경 한 내용과 이유 설명(어떻게 보다는 무엇과 왜를 설명한다)

9. 검토자가 원래 문제가 무엇인지 이해한다고 가정하지 말고 확실하게 설명 추가

10. 자신의 코드가 직관적으로 바로 파악 할 수 있다고 생각하지 말자

11. 팀에서 정한 Commit 규칙을 따르자

 

 

Tim pope의 커밋 메시지 템플릿

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some 
contexts, the first line is treated as the subject of an email and the rest of the text as 
the body. The blank line separating the summary from the body is critical (unless you omit 
the body entirely); tools like rebase can get confused if you run the two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." 
This convention matches up with commit messages generated by commands like git merge and 
git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a single space,
with blank lines in between, but conventions vary here

- Use a hanging indent

If you use an issue tracker, add a reference(s) to them at the bottom, like so:

Resolves: #123