[Git] 커밋 메시지 컨벤션

git 커밋 메시지

---

 

목차

깃 커밋 메시지란?

커밋 메시지를 작성해야 하는 이유

커밋 메시지 컨벤션이 중요한 이유

커밋 메시지 구조

커밋 메시지 유형

커밋 메시지 옵션

 

---

이번 게시글은 정답이 없습니다.

회사마다 팀마다 사람마다 기준이 다릅니다.

그래서 이 게시글은 가이드라인의 정도라고 생각하시고 봐주시면 감사하겠습니다.

 

---

[깃 커밋 메시지란?]

커밋 메시지는 깃에 내가 작성한 코드를 저장할 때 함께 작성하는 설명문이다.

이 코드가 어떤 코드인지 왜 이렇게 수정했는지 어떤 작업을 했는지 기록한다.

 

---

[커밋 메시지를 작성해야 하는 이유]

커밋 메시지를 작성하는 이유는 코드 변경사항에 대한 기록을 남겨 협업 효율성을 높이기 위해서다.

문제가 발생했을 때 코드 히스토리를 추적하며 빠르게 해결하기 위해서다.

• 협업 효율성 증가
  • 커밋 메시지를 잘 작성한다면 팀원들은 커밋 메시지를 통해 어떤 코드인지 쉽게 이해할 수 있다.
  • 효율적인 코드 리뷰가 가능하다.
  • 다른 팀원의 작업을 이해하는 데 도움이 된다.
• 코드 히스토리 추적
  • 커밋 메시지로 코드 변경의 히스토리를 기록한다.
  • 특정 기능이 추가되거나 버그가 수정된 시점을 쉽게 파악할 수 있다.
• 문제 해결 용이성
  • 커밋 메시지를 통해 문제가 발생한 지점을 빠르게 파악할 수 있다.
  • 해당 지점의 변경사항을 추적하여 원인을 찾고 해결할 수 있다.
• 프로젝트 유지보수 용이성
  • 잘 작성된 커밋 메시지는 유지보수 하는 데 큰 도움을 준다.
  • 코드 변경의 이유와 내용을 명확하게 설명하여 다른 개발자가 코드를 이해하고 수정하는 데 걸리는 시간을 줄여준다.
• 버전관리의 효율성
  • 커밋 메시지를 통해 코드 변경을 체계적으로 관리한다.
  • 필요에 따라 특정 시점으로 되돌아갈 수 있다.

 

<좋은 커밋 메시지 작성방법>

• 명확하고 간결하게 : 변경사항을 명확하게 설명하고 짧고 간결하게 작성한다.
• 구체적으로 작성 : 어떤 변경사항인지, 왜 변경했는지 구체적으로 작성한다.
• 의미 있는 제목 : 제목만 봐도 변경 사항의 내용을 알 수 있도록 작성한다.
• 컨벤션 준수 : 팀 또는 프로젝트에서 정한 커밋 메시지 컨벤션을 따른다.
• 적절한 상세 내용 : 필요한 경우 변경 사항에 대한 자세한 내용을 본문에 추가한다.

 

---

[커밋 메시지 컨벤션이 중요한 이유]

<Git 커밋 메시지 컨벤션이란?>

프로젝트 참여자들이 일관된 형식의 커밋 메시지를 작성하기 위한 규칙을 말한다.

 

깃 커밋 메시지는 코드 변경사항을 요약하여 전달하는 역할을 한다.

만약 프로젝트를 진행하면서 팀원들이 서로 다른 방식으로 커밋 메시지를 작성하면 메시지의 가독성이 떨어지고 문제 발생 시 이력을 추적하기 어려워진다.

그렇기 때문에 프로젝트 시작 전에 git 커밋 메시지 컨벤션(규약)을 정하는 것이 중요하다.

 

<git 커밋 컨벤션을 지켜야 하는 이유>

git 커밋 컨벤션을 지키는 것은 프로젝트 관리와 협업에 있어서 중요한 부분이다.

정해진 규칙에 따라 커밋 메시지를 작성하면 개발자들이 서로의 작업물을 이해하고 효율적으로 대처할 수 있기 때문이다.

 

• 가독성 및 커뮤니케이션 효율성
  • 일관된 커밋 메지시의 형태를 유지하면 가독성을 높일 수 있다.
  • 그러면 팀원들의 작업 내역이나 변경사항을 쉽게 파악할 수 있게 된다.
  • 코드 리뷰 및 버그 수정 과정에서 불필요한 의사소통 과정을 간소화하여, 프로젝트 관리에 들어가는 시간도 줄일 수 있다.
• 변경 이력 추적 및 문제 해결 속도 향상
  • git 커밋 컨벤션을 지키면 일관된 커밋 메시지를 통해 소스 변경 이력을 효율적으로 추적할 수 있다.
  • 이를 통해 문제 발생 시 더 빠르게 원인을 찾아 수정할 수 있어 전반적인 프로젝트 안정성을 높일 수 있다.

 

만약 팀원이

• fix
• 이거 수정함
• Test
• 여기 코드 바꿈

이런 식으로 커밋 메시지를 작성했다면 이 코드가 무엇인지, 왜 이런 작업을 했는지 모른다.

그렇기 때문에

• fix(api) : 로그인 시 토큰이 갱신되지 않는 문제 수정
• fix : 모달창이 닫히지 않는 버그 수정
• test : 유저 서비스 단위 테스트 추가
• refactore : 불필요한 콘솔로그 제거
• chore : 패키지 버전 업데이트
• feat : 로그인 페이지 UI 컴포넌트 생성

이런 식으로 내용을 구체화하는 것이 좋다.

 

---

[커밋 메시지 구조]

커밋 메시지에도 구조가 있다.

<type>[optional scope]:<description>    -- 헤더    => 제목(간단 요약)
					-- 빈 줄   => 빈칸
[optional body]                         -- 본문    => 내용
					-- 빈 줄   => 빈칸
[optional footer(s)]                    -- 바닥 글  => 주요 변경 사항, 이슈 해결 사항

 

git CLI에 적용하면 다음과 같다.

git cli에 적용한 커밋 메시지

 

여기서 ... 을 클릭하면

커밋 메시지

세부사항이 나타난다.

커밋 메시지 세부사항

 

<구조 설명>

<type>[optional scope]:<description>    -- 헤더    => 제목(간단 요약)
					-- 빈 줄   => 빈칸
[optional body]                         -- 본문    => 내용
					-- 빈 줄   => 빈칸
[optional footer(s)]                    -- 바닥 글  => 주요 변경 사항, 이슈 해결 사항

<Header>

❗메시지 끝에 . 금지❗

• <type> : 변경 사항의 유형 중 하나를 나타낸다.
  • 예시 : feat, fix, doc, style, refactor, test, chore 등
• [optional scope]
  • 선택 사항
  • 변경이 영향을 주는 모듈, 기능, 파일 범위 등을 적는다.
  • 예 : auth, api 등
• <description>
  • 변경작업의 제목으로 간단하게 요약하여 작성한다.
  • 50자 이내로 간결하게 작성하는 것이 좋다.
  • 영문인 경우 대문자로 시작하고 마침표를 사용하지 않는 것이 일반적이다.
  • 어떻게 보다는 무엇과 왜

<Content>

• [optional body]
  • 선택사항
  • 작업 내용이 복잡하거나 상세한 내용을 남겨야 하는 경우에만 작성한다
  • 필요한 경우 여러 줄로도 작성할 수 있다.
  • 약 72자 이내로 작성하는 것이 좋다.
  • 어떻게 변경했는지 보다 무엇을, 왜 변경했는지 작성한다
  • 변경한 내용과 이유 설명
  • 자신의 코드가 직관적으로 바로 파악할 수 있다고 생각하지 말기

<Footer>

• [optional footer(s)]
  • 선택사항
  • 이슈 id 명시하고 싶은 경우에 작성
  • 코드 작업과 관련 이슈를 해결한 경우 : Closes #작업번호 or 이슈번호
  • 여러 개의 이슈 번호는 쉼포(,)로 구분

 

<예시>

cli에서의 커밋 메시지

커밋 메시지

커밋 메시지 세부사항

 

❗주의❗

커밋을 어느 정도로 쪼개야 하는지에 대해서는 프로젝트 규모와 개발자 간의 작업 방식에 따라 달라질 수 있다.

그래서 git 커밋 메시지 컨벤션을 정할 때 미리 조율해 두는 것이 좋다.

팀에서 정한 commit 규칙을 따라야 한다.

 

❓질문❓

Q) 꼭 이 구조대로 메시지를 작성해야 하나요?

A) Header는 따르는 것을 추천합니다. Content와 footer는 선택사항으로 커밋 메시지 입력 시 입력하지 않아도 무관합니다.

 

---

[커밋 메시지 유형]

Tag Name <type>	Description
feat	기능 개발 수정
fix	버그 수정
chore	- 자잘한 디자인 수정, 기능 개발도 아닌 버그 수정도 아닌 무언가를 바꿨을 때 - 패키지 수정 - .gitignore
style	코드 스타일이나 ESLint 수정할 때 → 디자인 수정이 아니다.
refactor	코드 리팩토링
build	빌드 관련 파일이나 빌드할 때 관련 수정
design	css등 사용자 ui 디자인 변경
docs	문서 수정
test	- 테스트 코드 - 리팩토링 테스트 코드 추가 - Production Code(실제로 사용하는 코드) 변경 없음
rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
remove	파일을 삭제한느 작업만 수행한 경우
ci	ci 설정 파일 수정
pref	성능 개선
comment	필요한 주석 추가 및 변경
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
!BREAKING CHANCE	커다란 API 변경의 경우

 

<예시>

• fix(api) : 로그인 시 토큰이 갱신되지 않는 문제 수정
• fix : 모달창이 닫히지 않는 버그 수정
• test : 유저 서비스 단위 테스트 추가
• refactore : 불필요한 콘솔로그 제거
• chore : 패키지 버전 업데이트
• feat : 로그인 페이지 UI 컴포넌트 생성

 

---

[커밋 메시지 옵션]

옵션	설명	예시
m	커밋 메시지를 작성	git add file git commit -m "fix: 어떠한 기능 수정"
a or --all	모든 파일을 자동으로 commit(될 수 있으면 쓰지 않는 것을 추천	git commit -a -m "feat: 어쩌고 저쩌고 기능 추가"
-amend	원격 저장소로 푸쉬되지 않은 마지막 커밋 메시지를 다시 작성	git add . git commit --amend -m "ADD 다른 메시지 작성"

 

 

[TMI 더보기]

https://devyihyun.tistory.com/108

[Git] 커밋 메시지 수정하기

 

[깃 커밋 메시지 수정 방법]

• 커밋을 push 하기 전
• 커밋을 push 한 후 → 권장하지 않음

 

1. 커밋을 push 하기 전

CLI에서 git commit -amend를 입력하여 가장 최근에 만든 커밋 메시지를 수정할 수 있다.

터미널에서 vi/vim 편집기를 이용하는 경우에는 a 또는 i로 커서를 삽입하여 수정하면 된다.

그리고 수정을 완료한 후에는 ESC를 누른 후 :wq를 입력하여 변경사항을 저장해야 한다.

(vi/vim 편집기의 기본적인 명령어는 git 커밋 메시지 수정 전에 미리 익혀두는 것이 좋다.)

 

만약 수정해야 하는 Git 커밋 메시지가 가장 최근 커밋이 아닌 경우에는 git rebase -i HEAD~숫자 를 입력하여 수정할 커밋 메시지를 선택할 수 있다.

여기서 숫자는 최근까지 실행된 커밋 중 몇 개까지 살펴볼 것인지를 말한다.

 

rebase로 커밋 수정 화면에 들어가면 각 커밋 앞에 pick이 적혀있다.

수정하고자 하는 커밋 앞의 pick을 reword로 변경한 뒤 :wq로 저장하면 자동으로 해당 커밋을 수정할 수 있는 창이 열린다.

reword 외에 pick대신 edit를 사용할 수 있다.

이 경우에는 git rebase -continue를 사용하여 수정하고자 하는 다음 커밋으로 이동할 수 있다.

모든 커밋들에 대한 수정이 끝나면 자동으로 rebase 과정이 종료된다.

 

2. 커밋을 push 한 후

커밋을 push 한 후에는 커밋 메시지를 수정하는 것을 권장하지 않는다.

그 이유는 다른 개발자들이 해당 변경사항을 이미 pull 받을 수 있기 때문이다.

만약 이를 무시하고 강제로 push 하면 충돌이 발생할 수 있으니 이런 상황은 될 수 있으면 피하는 것이 좋다.

다만 그럼에도 불구하고 반드시 수정해야하는 경우라면 앞서 설명한 방법으로 커밋 메시지를 수정 후 git push --force를 입력하면 된다.

※ 참고로 저는 하지 않습니다.👀

 

[git 커밋 메시지 자동화 방안]

git 커밋 메시지를 작성할 때가 있는데 이걸 굳이 손으로 일일이 써야 하나?라는 생각이 든다.

만약 git 커밋 메시지를 자동으로 생성하거나, 모든 팀원이 컨벤션을 제대로 지키도록 강제하는 도구가 있다면 보다 효율적으로 git 커밋 이력을 관리할 수 있다.

<방법>

1. 깃 커밋 메시지 템플릿 설정
2. 깃 커밋 메시지 자동화 툴
3. 깃 커밋 메시지 템플릿 설정깃 커밋 메시지 템플릿을 설정하려면 기본 구조가 적힌 템플릿 파일
4. (ex. git_commit_template.txt를 생성한 후 gti config commit.template 명령어로 해당 템플릿 파일은 config에 등록하면 된다.)
5. 템플릿을 사용하면 메시지의 기본 주고를 제공함으로써 일관된 커밋 메시지를 유도할 수 있게된다.
6. 깃 커밋 메시지 자동화 툴대표적으로 깃 커밋 메시지를 검사하여 컨벤션을 따르는지 확인해주는 commitlint(https://commitlint.js.org/). git 훅(hookl)을 설정하여 커밋 및 푸시 전에 자동화된 작업(ex. 커밋 메시지 검사, 코드 포맷팅 등)을 설정할 수 잇는 hushy(https://typicode.github.io/husky/#/)와 같은 도구들이 있다.
7. 깃 커밋 메시지를 자동으로 생성하고 관리하기 위해서 다양한 자동화 도구들이 나와잇다.

 

 

---

잘못된 정보는 댓글에 남겨주시면 감사하겠습니다!😊

댓글과 좋아요는 큰 힘이 됩니다!

 

[ 참고자료 ]

https://yozm.wishket.com/magazine/detail/1974/

Git 커밋 메시지 컨벤션은 왜 중요할까? | 요즘IT

 

https://velog.io/@archivvonjang/Git-Commit-Message-Convention

[Git] Commit Message Convention

 

https://jane-aeiou.tistory.com/93

[Git] 좋은 commit message 작성법

 

https://richone.tistory.com/26

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

 

https://velog.io/@chojs28/Git-커밋-메시지-규칙

Git 커밋 메시지 규칙

 

https://velog.io/@jiheon/Git-Commit-message-규칙

[Git] Commit message 규칙

 

https://0soo.tistory.com/54

Git 커밋 메시지 작성법