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

 

 

 

들어가며

어떻게 하면 협업을 더 잘할 수 있을까 고민하며 협업에 필요한 내용들을 계속 정리하고 있습니다. 앞으로 저와 함께 협업하는 팀원분들에게 도움이 되고 싶습니다. 이 글은 Udacity Git Commit Message Style Guide를 주로 참고하여 작성했습니다. 세부적인 내용은 프로젝트에 맞춰 수정할 수 있습니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

대충 썼던 git Commit Message

왼쪽은 지금까지 제가 작성한 커밋 메시지이고, 오른쪽은 커밋 컨벤션을 공부하면서 적용한 커밋 메시지입니다.(다시 보니 고쳐야 할 점이 많습니다) 왼쪽을 지금 보니 매우 한숨만 나오는 커밋 메시지입니다. 이런 Commit Message가 많이 누적될수록 가독성은 매우 떨어집니다. 특히 여러 사람과 개발을 같이 할 때는 더욱 심각해집니다. 그리고 코드를 유지보수하기에도 어려워집니다. 하지만 협업하는 사람들 간의 커밋 메시지 스타일을 정해두면 서로 간의 코드 리뷰에 도움이 될 뿐 아니라, 자신의 이전 로그를 살펴보는 것에도 도움이 됩니다. Udacity의 깃 커밋 스타일 가이드를 바탕으로 커밋 컨벤션을 정리해보려 합니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

메시지 구조

먼저 커밋 메시지는 크게 제목, 본문, 꼬리말 세 가지 파트로 나누고, 각 파트는 빈줄을 두어서 구분합니다.

 

type(옵션): [#issueNumber - ]Subject  // -> 제목
(한 줄을 띄워 분리합니다.)
body(옵션) //  -> 본문 
(한 줄을 띄워 분리합니다.)
footer(옵션) // -> 꼬리말

 

• type : 어떤 의도로 커밋했는지를 type에 명시합니다. 자세한 사항은 아래서 설명하겠습니다.
• subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않습니다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기합니다. 
• body : 긴 설명이 필요한 경우에 작성합니다. 어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성합니다. 최대 75자를 넘기지 않도록 합니다. 
• footer : issue tracker ID를 명시하고 싶은 경우에 작성합니다.

 

그렇다면, 메시지 구조를 어떻게 더 명확하게 작성할 수 있는지, 살펴보겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

제목은 어떻게 작성하는가

 

타입

타입은 태그와 제목으로 구성되고, 태그는 영어로 쓰되 첫 문자는 대문자로 합니다. 

 

"태그: 제목"의 형태이며, : 뒤에만 space가 있음에 유의합니다.

 

태그 이름	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore	빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

 

 

 

 

태그는 어떻게 적는가?

태그는 다음과 같은 종류로 구분됩니다. 태그 뒤에는 ": "를 붙여 제목과 구별할 수 있도록 합니다.

 

1. 기능
2. 개선
3. 그 외

 

 

 

 

 

기능

Feat, Fix, Design, !BREAKING CHANGE 태그가 기능 태그의 종류입니다. 

 

Feat: 새로운 기능을 추가할 경우
Fix: 버그를 고친 경우
Design: CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE: 커다란 API 변경의 경우 (ex API의 arguments, return 값의 변경, DB 테이블 변경, 급하게 치명적인 버그를 고쳐야 하는 경우)

 

추가적인 문맥 정보를 제공하기 위한 목적으로 괄호 안에 적을 수도 있습니다.

 

ex)
"Feat(navigation): "
"Fix(database): "

 

 

 

 

 

개선

Style, Refactor, Comment 태그가 개선 태그의 종류입니다.

 

Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor: 프로덕션 코드 리팩토링, 새로운 기능이나 버그 수정없이 현재 구현을 개선한 경우
Comment: 필요한 주석 추가 및 변경

 

Style의 경우 오타 수정, 탭 사이즈 변경, 변수명 변경 등에 해당하고, Refactor의 경우 코드를 리팩토링 하는 경우에 적용할 수 있습니다. 

 

 

 

 

 

 

그 외

Docs, Test, Chore, Rename, Remove 태그가 그 외 태그의 종류입니다.

 

Docs: 문서를 수정한 경우
Test: 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 없음)
Chore: 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)
Rename: 파일 혹은 폴더명을 수정하는 경우
Remove: 사용하지 않는 파일 혹은 폴더를 삭제하는 경우

 

Docs의 경우 README.md 수정 등에 해당하고, Test는 test 폴더 내부의 변경이 일어난 경우에만 해당합니다. Chore의 경우 package.json의 변경이나 dotenv의 요소 변경 등, 모듈의 변경에 해당됩니다. 

 

그렇다면, 좋은 커밋 메시지를 작성하기 위해서는 제목은 어떻게 작성해야 하는지 알아보겠습니다.

 

 

 

 

 

 

 

 

제목은 어떻게 적는가?

 

제목은 코드 변경 사항에 대한 짧은 요약을 나타냅니다. 제목은 다음의 규칙을 지킵니다.

 

1. 제목의 처음은 동사 원형으로 시작합니다.
2. 총 글자 수는 50자 이내로 작성합니다.
3. 마지막에 특수문자는 삽입하지 않습니다. 예) 마침표(.), 느낌표(!), 물음표(?)
4. 제목은 개조식 구문으로 작성합니다.

 

만약 영어로 작성하는 경우 다음의 규칙을 따릅니다. 

 

1. 첫 글자는 대문자로 작성합니다.
2. "Fix", "Add", "Change"의 명령어로 시작합니다.

 

한글로 제목을 작성하는 경우 다음의 규칙을 따릅니다.

 

1. "고침", "추가", "변경"의 명령어로 시작합니다.

 

예시)
Feat: "추가 get data api 함수"

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

본문은 어떻게 작성하는가

 

본문은 다음의 규칙을 지킵니다.

 

1. 본문은 한 줄 당 72자 내로 작성합니다.
2. 본문 내용은 양에 구애받지 않고 최대한 상세히 작성합니다.
3. 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

꼬리말은 어떻게 작성하는가

 

꼬리말은 다음의 규칙을 지킵니다.

 

1. 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
2. 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.
3. 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
4. 이슈 트래커 유형은 다음 중 하나를 사용합니다.
    - Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
    - Resolves: 이슈를 해결했을 때 사용
    - Ref: 참고할 이슈가 있을 때 사용
    - Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
ex) Fixes: #45 Related to: #34, #23

 

지금까지 배운 내용을 토대로 로그인 API를 개발한 내용을 커밋할 때, 커밋 메시지를 작성한다면 어떻게 작성할 수 있을까요?

 

Feat: "추가 로그인 함수"

로그인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

커밋 메시지 Emoji

---

Emoji	Description
🎨	코드의 형식 / 구조를 개선 할 때
📰	새 파일을 만들 때
📝	사소한 코드 또는 언어를 변경할 때
🐎	성능을 향상시킬 때
📚	문서를 쓸 때
🐛	버그 reporting할 때, @FIXME 주석 태그 삽입
🚑	버그를 고칠 때
🐧	리눅스에서 무언가를 고칠 때
🍎	Mac OS에서 무언가를 고칠 때
🏁	Windows에서 무언가를 고칠 때
🔥	코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜	파일 구조를 변경할 때 . 🎨과 함께 사용
🔨	코드를 리팩토링 할 때
☔️	테스트를 추가 할 때
🔬	코드 범위를 추가 할 때
💚	CI 빌드를 고칠 때
🔒	보안을 다룰 때
⬆️	종속성을 업그레이드 할 때
⬇️	종속성을 다운 그레이드 할 때
⏩	이전 버전 / 지점에서 기능을 전달할 때
⏪	최신 버전 / 지점에서 기능을 백 포트 할 때
👕	linter / strict / deprecation 경고를 제거 할 때
💄	UI / style 개선시
♿️	접근성을 향상시킬 때
🚧	WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎	New Release
🔖	버전 태그
🎉	Initial Commit
🔈	로깅을 추가 할 때
🔇	로깅을 줄일 때
✨	새로운 기능을 소개 할 때
⚡️	도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡	새로운 아이디어, @IDEA주석 태그
🚀	배포 / 개발 작업 과 관련된 모든 것
🐘	PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)
🐬	MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🍃	MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦	일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳	도커 구성
🤝	파일을 병합 할 때

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

마치며

지금까지 git의 커밋 컨벤션에 대해서 알아봤습니다. 협업을 위해 커밋 메시지를 보다 더 정성스럽게 쓰는 연습을 해야겠다고 생각했습니다. 앞으로 다양한 커밋메시지를 작성하면서, 계속해서 더 좋은 커밋메시지를 작성할 수 있도록 연습하려 합니다. 처음부터 잘하는 사람은 없으니, 협업에 특화된 개발자가 되도록 노력하겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

참고

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : TOAST Meetup

나만의 commit message 작성법

slashsbin/styleguide-git-commit-message