[Git] Github, Git Commit Rule (깃허브 커밋 룰)

---

서  론

깃허브(Github)를 위시한 각종 Git들이 포트폴리오 대용으로까지 활용되는 시대에,

사실 너무 많은 git들이 막 올려지고 있고, 너무 많은 사람들이 제대로 된 Git Commit Rule이 무엇인지는 커녕 존재하는지조차 모르고 있다.

 

사실 필자도 Git Commit Rule이란 것이 뭔지 한동안은 몰랐었다.

(심지어 아직도 너무 마이너한 커밋은 아주 짧은 커밋 메시지만을 (initial commit 등) 작성한 채 push 해버린다.)

 

무엇보다 귀찮기 때문이 아닐까,

라는 핑계거리는 있지만……

 

N모사의 한 책임개발자는 "신입을 뽑을 때 깃 커밋 메시지만 봐도 뽑아야할지 말아야할지 알 수 있다"라고 말한 것을 들은 적이 있다.

 

사실 취업에 있어서, 경력이 아닌 신입 채용에서 가장 중요한 것은 태도이다.

괜히 다들 열정을 내세우는 것이 아니다.

 

어차피 10년차, 20년차 현업 경력자 앞에서는 아무리 대학에서 날고 기는 사람이라고 해봤자 햇병아리일 뿐이고,

그런 그들에게 어필할 수 있는 가장 큰 무기는 "성장 가능성"이기 때문이다.

 

그런데 취준생이 생각하는 "성장 가능성"이 자기자신의 프로그래밍적 기술의 성장이라면,

회사가 생각하는 "성장 가능성"은 빠르게 써먹을 수준이 되는 성장에 더 가까울 것이라 생각한다.

 

그리고 회사는 협업의 장이다.

그러므로 빠르게 써먹을 수 있으려면 협업을 잘해야한다.

 

그게 우리가 깃 커밋 룰을 알아야하고, 지켜야하는 이유다.

사람끼리 같이 일하기 위해서.

---

Git Commit Rule / Git Commit Message Convention

그러니까 결국 깃 커밋 룰을 지켜야 하는 것은 협업을 하기 위해서라는 소리인데,

협업을 할 때 왜 깃 커밋 룰이 필요할까?

 

일단 학부 때 필자의 경우를 생각해보면,

(사실 아직도 그러긴 하지만…)

깃헙에다가 작성 완료된 소스 코드를 그냥 올리고 그만이었다.

CLI로 굳이 올려야 하나…? 라는 생각도 했었다.

 

그건 혼자 코딩하고 혼자 깃허브에 올리기 때문이다.

 

회사에서 협업하기 위해서는 반드시 Branch를 따야하며, (devel 브랜치 등 브랜치의 이름은 회사마다 다름)

브랜치로 커밋을 했다가 마지막에 Merge Request를 해야한다.

그때 난리가 난다고 해서 위 짤이 생겨나기도 했다.

 

그렇다면 이제 배경설명은 그만하고, 깃 커밋 룰에 대해 알아보도록 하자.

---

1. 커밋 메시지 구조

• 기본적으로 커밋 메시지는 아래와 같이 제목/본문/꼬리말로 구성한다.

Type : Subject

body

footer

2. 커밋 종류

- feat 		: 새로운 기능 추가
- fix 		: 버그 수정
- docs 		: 문서 수정
- style 	: 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
- refactor 	: 코드 리팩토링
- test 		: 테스트 코드, 리팽토링 테스트 코드 추가
- chore 	: 빌드 업무 수정, 패키지 매니저 수정

3. 제목

• 제목은 50자를 넘기지 않고, 마침표를 붙이지 않는다.
• 제목에는 위 커밋 종류를 함께 쓴다.
• 과거시제를 사용하지 않고 명령조로 작성한다.
• 제목과 본문은 한 줄 띄워 분리한다.
• 제목의 첫 글자는 반드시 대문자로 쓴다.
• 제목이나 본문에 이슈 번호(가 있다면) 붙여야 한다.

4. 본문

• 선택사항이기에 모든 커밋에 본문 내용을 작성할 필요는 없다.
• 한 줄에 72자를 넘기면 안된다.
• 어떻게(How)보다 무엇을, 왜(What, Why)에 맞춰 작성한다.
• 설명뿐만 아니라, 커밋의 이유를 작성할 때에도 쓴다.

5. Footer

• 선택사항이기에 모든 커밋에 꼬릿말을 작성할 필요는 없다.
• Issue Tracker ID를 작성할 때 사용한다.

예시)

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

---

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

---