Git 커밋을 작게 나누면 나중에 고생이 줄어든다

하루 종일 작업하고 퇴근 직전에 git add . && git commit -m "작업 완료"를 찍는 습관이 있었다. 당시엔 빠르고 편했지만, 일주일 뒤 버그를 찾으려고 git log를 열면 커밋 하나에 너무 많은 게 섞여 있어서 원인을 추적하기 어려웠다.

작은 커밋이 실제로 도움이 되는 상황

git revert: 특정 기능을 되돌려야 할 때, 그 기능이 독립된 커밋으로 남아 있으면 git revert <hash> 한 줄로 끝난다. 다른 기능과 섞여 있으면 충돌을 손으로 풀어야 한다.

git bisect: 버그가 언제 생겼는지 이진 탐색으로 찾을 때, 커밋 단위가 작을수록 원인이 되는 커밋을 빠르게 특정할 수 있다.

코드 리뷰: 커밋 하나에 리팩토링과 기능 추가가 섞여 있으면 리뷰어가 무엇을 봐야 하는지 파악하기 힘들다.

git add -p로 hunk 단위로 스테이징한다

파일 전체가 아니라 변경 덩어리(hunk) 단위로 스테이징하는 방법이다.

git add -p

실행하면 변경된 코드 블록마다 Stage this hunk?를 묻는다. y는 포함, n은 제외, s는 더 잘게 나누기, e는 수동 편집이다. 한 파일 안에서도 관련 없는 변경이 섞였을 때 분리할 수 있다.

커밋 메시지 패턴

커밋이 작아지면 메시지도 자연스럽게 구체적으로 쓰게 된다.

# 나쁜 예
feat: 작업 완료

# 좋은 예
feat: 게시글 목록 페이지에 무한 스크롤 추가
fix: 모바일에서 헤더 메뉴가 닫히지 않는 문제 수정
refactor: PostCard 컴포넌트에서 날짜 포매팅 유틸로 분리

동사 하나로 설명할 수 없는 커밋이라면 두 개로 나눌 신호다.

혼자 개발할 때도 가치가 있다

팀이 없으면 커밋 메시지나 단위를 신경 쓰지 않기 쉽다. 하지만 몇 달 뒤 같은 코드를 다시 볼 때의 나는 사실상 다른 사람이다. git log --oneline이 작업 이력처럼 읽히면, 어디서 무엇이 바뀌었는지 파악하는 데 걸리는 시간이 확연히 줄어든다.