Git Commit Message Convention

 

최근에 Git 으로 협업을 해야하는 상황이 생겼고, 앞으로도 쭉 그럴 것 같다. 이번에 Git을 처음 사용하는 것도 아니지만, 지금까지는 혼자서 개발 공부를 했던 터라 제멋대로 사용을 해왔다.

 

하지만 다른 사람들과 협업을 하는 과정에서는 사소한 규칙 하나하나가 중요하고, 하나라도 잘 지켜지지 않는 경우에는 작업 효율에 영향을 미치게 된다.

 

그렇기 때문에 협업을 위해서 구성원들과 지켜야 하는 다양한 convention이 존재한다. 이번에는 그 중에서 커밋 메세지에 대해서 정리해보려고 한다.

 

해당 포스팅은 다음 블로그의 내용을 참고하여 작성하였다. 두 포스팅 모두 udacitiy 에 나와 있는 Udacity Git Commit Message Style Guide 를 참고 하셨다고 나와있다

깃 커밋 메시지 컨벤션 (Git Commit Message Convention)

 

[협업] 협업을 위한 git 커밋컨벤션 설정하기

 

 

Commit Message Structure

---

type(옵션): Subject // 헤더
(빈 줄)
body(옵션) // 본문
(빈 줄)
footer(옵션) // 꼬리말

 

 

Type

---

커밋 메세지의 타입은 헤더의 앞부분에 들어가고, 콜론(: ) 으로 subject 와 구분한다.

타입은 커밋의 의도를 명시하는 역할을 하고, 아래의 타입 종류 중 하나로 선택된다.

 

Type
feat	새로운 기능 추가 (A new feature)
fix	버그 수정 (A bug fix)
docs	문서 수정 (Changes to documentation)
style	포매팅, 세미콜론 누락, 코드 변경이 없는 경우(Formatting, missing semi colons, etc; no code change)
refactor	리팩터링 (Refactoring production code)
test	테스트 코드 추가, 리팩터링 테스트 (Adding tests, refactoring test; no production code change)
chore	빌드 작업 수정, 패키지 매니저 설정 (Updating build tasks, package manager configs, etc; no production code change)

 

 

Subject

---

제목은 해당 커밋을 설명할 수 있는 문장이다.

• 제목은 50자를 넘기지 않는다.
• 영문으로 작성할 경우 첫 글자는 대문자로 시작한다.
• 문장을 마침표로 끝내지 않는다.
• 문장은 명령형 어조로 작성한다.
• 커밋이 무엇을 했는지 보다는 무엇을 하는지의 느낌으로 작성한다.

 

 

Body

---

모든 커밋이 본문을 사용해야 할 만큼 복잡하지는 않으므로, 본문은 선택 사항이다. 보통 커밋에 대한 설명이 제목만으로 부족한 경우에 작성한다.

• 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지 를 설명한다.

 

 

Footer

---

꼬리말 또한 선택적으로 사용하고, issue 를 추적하기 위해서 사용한다.

• footer type: #이슈 번호 형식으로 사용한다.
• 여러 개의 이슈 번호를 적을 때는 쉼표로 구분한다.
• 이슈 트래커 유형(footer type)은 다음 중 하나를 사용한다.
  • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to(See also): 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)

 

 

Commit Message Example

---

feat: Summarize changes in around 50 characters or less

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 the commit 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); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

 

others

GitHub - angular/angular: The modern web developer’s platform

 

 

정리

---

Git을 배우기 시작할 때 가장 먼저 봤던 것이 깃의 목적이었다. git의 목적은 버전 관리와 협업이라고 했던 것이 기억난다. 개인 프로젝트와 공부를 하면서 버전 관리의 목적으로 Git은 유용한 도구였다. 하지만 그렇게만 사용하다 보니 또 다른 목적인 협업에 대해서 전혀 신경쓰지 않았던 것 같다.

협업을 위해서는 구성원들 간에 컨벤션 협약이 이루어져야 한다. 컨벤션이 존재하지 않거나, 지켜지지 않는 다는 이유만으로도 충분히 업무 진행에 차질이 생기기 때문이다. 그렇기 때문에 평소에도 양식에 맞게 적절한 커밋과 커밋 메시지를 작성하는 연습이 반드시 필요하다.

물론 모두가 똑같은 컨벤션을 따르는 게 아닐 것이다.  공동체마다 정해진 컨벤션이 존재할 것이고, 당연히 그 구성원이라면 공동체의 컨벤션을 따라야한다. 그럼에도 불구하고 공통적으로 적용되는 부분에 대해서는 혼자라도 의식적으로 연습을 하는 것이 좋다고 생각이 든다.

지금까지 나는 협업을 많이 해보지 않았다. 학교에서 처음 Github을 사용했을 때는 Git이 뭔지도 모르고 그냥 사용했다. 프로젝트가 끝날 때 쯤에 커밋이 3개 정도 올라갔던가... 지금 생각해면 정말 웃기다.

하지만 그 이후로도 나의 커밋 메세지는 들쭉 날쭉 일관성이 없었다. 작업 단위로 나누어서 커밋을 하지도 않았고, 그냥 내가 생각이 날 때마다 커밋을 했던 것 같다. 이런 방식은 커밋을 하는 이유가 전혀 없다. 컨벤션에 대해서 공부해보니, 협업을 위해서도 중요하지만 작업의 단위를 적절하게 나누어서 진행하고, 작업 이력을 관리하는 목적으로도 정말 많은 도움이 된다고 생각한다. 앞으로는 나도 의식적으로 이를 지켜나갈 것이고, 쓸모있는 커밋을 만들도록 노력해야겠다.