커밋 위생은(는) 무엇을 하나요?
개요
재럿의 규칙 제4조: 변경에는 논리적으로 필요한 커밋만 있어야 합니다. 리뷰어는 각 변경에 대해 시행착오의 역사가 아닌, 하나의 깔끔한 커밋을 봅니다. 주석은 짧게 작성합니다.
commit-check 훅은 git commit 메시지가 제한을 위반할 때 경고합니다. 이를 막지는 않으며, 개발자가 직접 커밋을 수정합니다.
사용 시점
- 각 커밋 전.
- 각 푸시 전.
- 하나의 이슈를 고치기 위해 두 개 이상의 커밋을 만들었을 때.
commit-check훅이 경고할 때.
프로세스
1. 메시지 작성
- 제목: 72자 이하. 명령형 사용: "Add rules hook" (O), "Added rules hook" (X)
- 본문: 5줄 이하. 제목만으로 충분하면 본문 생략.
- 변경된 내용과 이유를 작성하세요. 각 파일을 설명하지 마세요.
- 간결한 영어를 사용하세요.
simplified-english스킬을 참고하세요.
2. 논리적 변경당 하나의 커밋
- 하나의 논리적 변경: 리뷰어가 하나의 단위로 수락하거나 거절할 수 있는 기능 조각, 수정 또는 리팩터링.
- 하나의 커밋에 리팩터링과 동작 변경을 섞지 마세요.
- 각 시도마다 커밋하지 마세요. 변경이 작동하고 테스트가 통과할 때 커밋하세요.
3. 푸시 전에 수정 커밋 스쿼시
수정 커밋은 동일한 변경에서 이전 커밋을 바로잡습니다. 예시: "fix typo", "wip", "address review"
git commit --fixup <sha>로 수정 커밋을 만듭니다.- 편집기 없이 스쿼시:
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base> - 리베이스가 충돌로 중단되면 파일을 수정하고
git add <파일>을 실행합니다. 그런 다음GIT_EDITOR=true git rebase --continue를 실행합니다. 중단하려면git rebase --abort를 실행합니다. - 테스트를 다시 실행합니다.
- 결과 확인:
git log --oneline <base>..HEAD
마지막 커밋이 수정 대상이라면 git commit --amend --no-edit을 사용하세요.
경고: 이미 공유 브랜치에 있는 커밋은 다시 작성하지 마세요. 먼저 사용자에게 물어보세요. 다시 작성하면 팀원 각자가 리셋해야 합니다.
4. 주석 짧게 유지
- 코드가 명확하지 않을 때만 주석을 작성하세요.
- 한 줄이면 충분합니다. '무엇'이 아닌 '이유'를 적으세요.
- 주석에 변경 내역을 기록하지 마세요. Git이 히스토리를 관리합니다.
흔한 합리화
| 합리화 | 현실 |
|---|---|
| "작은 커밋이 제 진행 상황을 보여줍니다." | 리뷰어는 결과가 필요하지 경로가 필요하지 않습니다. 시도들은 스쿼시하세요. |
| "긴 메시지가 더 많은 맥락을 제공합니다." | 긴 메시지는 읽히지 않습니다. 맥락은 스펙이나 PR에 넣으세요. |
| "나중에 스쿼시할게요." | '나중'은 푸시 후입니다. 푸시 전에 스쿼시하세요. |
| "훅이 경고만 하니까 제한은 선택사항이에요." | 제한은 팀 규칙입니다. 훅은 수정할 수 있도록 경고하는 것입니다. |
위험 신호
git log에 푸시 전 "wip", "fix", "oops", "try again"이 표시됨- 하나의 버그 수정에 두 개 이상의 커밋
- 변경된 각 파일을 나열하는 커밋 본문
- 코드가 말하는 내용을 반복하는 주석
검증
- 각 제목이 72자 이하이고 명령형을 사용함
- 각 본문이 5줄 이하임
-
git log --oneline <base>..HEAD가 각 논리적 변경에 대해 하나의 커밋을 보여줌 - 푸시 전에 수정 커밋이 남아 있지 않음
- 리베이스 후 테스트 통과
알려진 한계: 훅은 git -C <dir> commit 또는 git -c <key>=<value> commit을 확인하지 않습니다. 또한 -F <file>과 같이 읽을 수 없는 일부 메시지는 건너뜁니다.