다른 사람과 협업하는 경우든 혼자 작업하는 경우든 간에, 커밋 메시지에 내가 한 작업을 왜 했는지 잘 기록하려고 한다. 변경된 코드만 보고 어떤 걸 작업한 건지 유추하는 것보단 잘 정리된 커밋 메시지를 읽는 게 프로젝트 변경 이력 파악에 더 용이하다고 생각하기 때문이다.
여러 프로젝트에서 git으로 버전 관리를 하면서, 커밋 메시지를 잘 써보려고 이래저래 노력했다. 하지만 그렇더라도 '이건 뭐라고 메시지를 써야하지?' 싶은 때가 많았다. 그렇다고 메시지만 붙들고 있기엔 더 중요한 다른 작업도 많아서 만족스럽지 않은 채로 메시지를 쓴 채 다른 작업으로 넘어가기 일쑤였다.
언젠가부터 떠올린 생각은, '그러면 일단 지금 생각나는 최선을 적고, 나중에 더 낫게 다듬는' 방법이다. 나는 이 '나중에'를 여러 시점으로 보고, 각 시점마다 수정할 수 있는 방법을 찾았다. 작업 주기별로 메시지를 수정할 수 있게 되고 나서는 '당장 좋은 아이디어가 생각이 안나'서 다른 작업을 못하는 상황에서 벗어날 수 있었고, 더 유동적으로 쓸 수 있게 되었다. 글에서 구체적으로 어떤 식으로 하는지 공유한다.
처음 커밋을 만들 때, git 커밋 편집기에서 해당 커밋에서 바뀐 내용이 뭔지를 같이 보여준다. 바뀐 파일명 목록만 보는 것보다는 각 파일에서 바뀐 내용을 보면서 어떤 내용을 써야할지 한번 더 생각해볼 수 있다.
새로 커밋을 만들지 않은 상황이라면, 마지막 커밋 메시지를 이 명령으로 바꿀 수 있다. 소스를 변경하지 않고 커밋 메시지만 수정할 수도 있고, 소스 변경과 커밋 메시지 수정 모두 할 수도 있다.
최신 커밋 이전에 한 커밋 메시지를 수정하고 싶다면, 이 명령으로 바꿀 수 있다. 여러 커밋의 메시지를 수정할 수도 있다. 개인적으로 이 명령을 쓸 때 번거로운 건 다른 것보다 'rebase하려는 커밋 범위가 어디까지인지 파악하는 것'이다. 나는 보통 브랜치를 만들어서 작업 후 깃헙 PR로 main 브랜치에 머지하는 편인데, 그래서
git log --pretty=oneline --abbrev-commit main..other | wc -l로 main 브랜치에는 없고 other 브랜치에만 있는 커밋의 갯수 x를 알아낸 후,
git rebase -i @~x로 interactive rebase를 실행한다. 그러면 other 브랜치에서 작업한 커밋 중에 고치고 싶은 걸 한꺼번에 모아서 수정할 수 있다.
git push로 원격 저장소에 작업을 올려서 PR을 만든 후에도 커밋 메시지를 바꿀 수 있다. PR을 머지하는 시점이 그 때다. create merge commit 대신 squash and merge 옵션을 선택하면 해당 PR에 포함된 모든 커밋이 하나의 커밋으로 합쳐지고, 이 커밋의 메시지는 해당 PR에 포함된 각 커밋 메시지를 합친 것이 된다. 이때 커밋 메시지를 수정해서 작업 내용을 한 번 더 정리할 수 있다. 각 커밋 메시지를 읽으면서 해당 PR에서 뭘 하려고 했는지를 잘 표현하는지 따져보고, 더 괜찮은 아이디어가 있다면 squash 커밋 메시지에 적을 수 있다.