[Git] 깃 커밋 메시지 작성법(git 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

 

 

 

참조 : https://udacity.github.io/git-styleguide/

Udacity Nanodegree Style Guide

출처 : https://richone.tistory.com/26