더 나은 Git 커밋 메시지 작성하기
커밋 옵션, 컨벤션, 템플릿 등
무조건 git commit -m으로만 커밋 메시지를 작성했던 지난 날.. 이걸로만은 한계를 느껴 커밋 메시지에 대해 좀 더 알아보았다.
-m: 인라인 형식으로 바로 커밋 메시지 작성
git commit -m "커밋 메시지"
-a 또는 --all: 별도의 add 명령어를 사용하지 않고, 수정된 모든 파일에 대해 add, commit을 한번에 수행(단, 한번도 add되지 않은 파일은 add를 따로 해주어야 함)
git commit -a -m "커밋 메시지"
-am: a, m 옵션을 합친 형태(파일을 스테이지에 올리고 커밋)
git commit -am "커밋 메시지"
--amend 옵션으로 가장 최근에 만든 커밋 메시지 수정하기
git commit --amend -m "수정할 커밋 메시지"
수정하고자 하는 커밋이 가장 최근 커밋이 아닌 경우
git rebase -i HEAD~[숫자]
숫자는 최근까지 실행된 커밋 중 몇 개까지 살펴볼 것인지를 말한다. 예를 들어 2를 입력 시, 최근 커밋보다 이전에 커밋된 2개의 git 메시지를 수정 가능하다.
위 명령어를 통해 수정화면에 들어가면 각 커밋 앞에 pick이 적혀있다.
수정하고자 하는 커밋 앞의 pick을 reword로 변경한 뒤 저장하면 해당 커밋을 수정할 수 있는 창이 열린다. (i를 눌러 내용을 수정하고, esc를 누른 후 :wq를 입력하면 저장할 수 있다.)
자세한 과정은 아래에 있는 gif를 참고하면 된다.
이 경우 다른 개발자들이 해당 변경사항을 이미 pull 받았을 수도 있기 때문에 커밋 메시지를 수정하는 것을 권장하지 않는다. 하지만 그럼에도 불구하고 반드시 수정해야 하는 경우라면 위에서 설명한 방법으로 커밋 메시지를 수정한 후 git push --force를 입력하면 된다.
-amend 또는 rebase -i HEAD~로 커밋 메시지 수정
git push --force
이미 push한 커밋을 rebase -i로 메시지 수정 후 --force로 푸시
커밋 메시지 컨벤션이란 프로젝트 참여자들이 일관된 형식의 커밋 메시지를 작성하기 위한 규칙을 말한다.
일관된 커밋 메시지의 형태를 유지하면 가독성을 높일 수 있고, 소스 변경 이력을 효율적으로 추적할 수 있다.
또한 코드 리뷰 및 버그 수정 과정에서 불필요한 의사소통 과정을 간소화해 프로젝트 관리에 들어가는 시간을 줄일 수 있다.
일반적으로 아래와 같은 형태로 작성한다.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
type과 description은 필수적으로 작성하고, scope, body, footer는 필요에 따라 작성해주면 된다. (e.g. feat: 로그인 기능 추가)
type에는 상황에 따라 다음과 같은 단어들이 들어가면 좋다.
FEAT: 새로운 기능 추가
FIX: 버그 수정
DOCS: 문서 수정
STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
REFACTOR: 코드 리팩토링
TEST: 테스트 코드 추가
CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
사소한 변경으로 커밋 메시지를 한 줄만 작성해도 괜찮은 경우도 있다. 이럴 경우에는 본문을 쓰지 않아도 괜찮다.
하지만 어떤 변경 사항인지 맥락과 설명이 필요하다면 본문을 작성해야 한다. 제목과 본문을 구분해서 작성할 때는 무조건 그 사이에 빈 행이 존재해야 제대로 동작한다.
이는 강제로 제한하는 규칙이 아닌 경험에 의한 규칙이다.
이 길이로 하면 읽기 편하고, 작성자가 무슨 일이 일어나는지 간결하게 작성하는 데 집중할 수 있도록 돕게 된다.
(제목을 요약하는 것이 너무 어렵다면 한 번에 커밋하기에 너무 많은 변경을 포함하는 경우일 수도 있다.)
'왜' 이렇게 바꾸었는지에 먼저 주목하자. 바꾸기 전에 무엇을 했는지(무엇이 잘못 동작했는지), 지금은 어떻게 동작하는지, 그리고 왜 당신이 그렇게 바꾸기로 했는지에 대해 적자.
커밋 메시지 템플릿을 이용하면 일관된 커밋 메시지를 작성하도록 유도할 수 있다.
기본 구조가 적힌 템플릿 파일을 생성한 후, git config commit.template 명령어로 해당 템플릿 파일을 git config에 등록하면 템플릿을 사용할 수 있다.
먼저 .gitmessage.txt라는 이름의 파일을 생성한 후, 파일에 아래 내용을 붙여넣고 저장한다.
################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) FEAT: 로그인 기능 추가
# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)
################
# 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)
################
# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Close #7
################
# FEAT: 새로운 기능 추가
# FIX: 버그 수정
# DOCS: 문서 수정
# STYLE: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
# REFACTOR: 코드 리팩토링
# TEST: 테스트 코드 추가
# CHORE: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
################
#으로 시작하는 부분은 주석으로, 커밋에 반영되지 않는다.
아래 명령어를 통해 템플릿 파일을 설정할 수 있다. 이렇게하면 git commit 명령을 실행할 때 지정한 템플릿 메시지를 편집기에서 매번 사용할 수 있다.(-m 옵션을 사용하지 않고 git commit만 입력하면 된다.)
git config --global commit.template .gitmessage.txt
따로 범위 옵션을 지정하지 않으면 git은 기본적으로 --local 옵션을 지정한다. 상황에 따라 맞는 옵션을 선택해 지정해주면 된다.
--system: 해당 시스템에 있는 모든 사용자와 모든 저장소에 적용되는 설정 파일
--global: 해당 사용자에게만 적용되는 설정 파일(내 로컬에서 커밋하는 모든 프로젝트에서 동일한 템플릿이 적용됨)
--local: 현재 작업 중인 저장소의 git 디렉토리에 있는 파일을 찾는다. 이 파일은 해당 저장소에만 적용된다.
먼저 git add 명령어를 통해 변경사항이 있는 파일을 스테이지에 올린다. 그 후 git commit을 실행한다.(-m 옵션을 빼고 git commit만 입력하면 설정한 템플릿이 나온다.)
vi 에디터가 나오면 i를 눌러 편집모드로 변경 후 내용을 작성한다. 입력이 완료되었으면 esc를 누른 후 :wq를 입력해 저장해주면 커밋이 완료된다.
작업이 끝났다면 git push를 통해 커밋을 원격 저장소에 올릴 수 있다.
git 커밋 메시지를 자동으로 생성하고 관리하기 위한 다양한 자동화 도구들이 있다.
commitlint: git 커밋 메시지를 검사해 컨벤션을 따르는지 확인
Husky: git hook을 설정해 커밋 및 푸시 전에 자동화된 작업(커밋 메시지 검사, 코드 포매팅 등)을 설정할 수 있음.
댓글 3
공손한 두루미
신기하당
공손한 두루미
비밀댓글이에요
추천 포스트
