커밋 메시지·작성자·날짜를 엑셀처럼 고친다, 깃 히스토리 편집 도구 'git-knife'

푸시하고 나서야 발견하는 커밋 메시지 오타, 개인 프로젝트인데 회사 이메일로 찍혀 있는 작성자 정보. 다들 한 번쯤 겪어보셨을 텐데요. 이걸 고치려면 보통 git rebase -i를 열어서 커밋마다 reword를 지정하고, 에디터가 하나씩 뜰 때마다 메시지를 고치는 과정을 반복해야 해요. 커밋이 한두 개면 몰라도 열 개쯤 되면 꽤 고역이죠. 오늘 소개할 git-knife는 이 작업을 스프레드시트 다루듯 바꿔주는 도구예요. 커밋 목록을 표로 띄워 놓고, 셀 고치듯 메시지·작성자·날짜를 수정한 다음 한 번에 적용하는 방식이거든요.

커밋에 붙어 있는 것들

먼저 배경 지식부터 짚고 갈게요. 커밋에는 코드 변경분 말고도 메타데이터가 붙어 있어요. 커밋 메시지, 작성자(author) 이름과 이메일, 그리고 날짜인데요. 날짜가 두 종류라는 건 의외로 모르는 분이 많아요. 코드를 처음 작성한 시점인 author date와, 그 커밋이 히스토리에 기록된 시점인 commit date가 따로 있거든요. rebase나 cherry-pick을 하면 이 둘이 서로 달라져요. 기존에 이런 메타데이터를 고치는 방법은 상황마다 달랐어요. 마지막 커밋 하나면 git commit --amend, 그 이전 커밋들은 git rebase -i, 작성자 이메일을 저장소 전체에서 일괄 변경하려면 git filter-repo 같은 별도 도구까지. 각각 사용법이 다르고, 익숙하지 않으면 실수하기도 쉽죠.

git-knife는 어떻게 다를까

git-knife는 이 흩어진 작업을 하나의 표 인터페이스로 모았어요. 행 하나가 커밋 하나이고, 열이 메시지·작성자·이메일·날짜인 표를 띄워 주는 거예요. 엑셀에서 여러 셀 고치듯 필요한 값들을 수정하고 적용하면, 도구가 알아서 히스토리를 다시 써 줘요. '무엇을 바꿀지'와 '어떻게 바꾸는지'를 분리해 준다는 게 핵심이에요. 사용자는 결과물만 표에서 편집하고, rebase의 복잡한 절차는 도구가 감춰 주는 거니까요.

반드시 알아야 할 것: 해시는 전부 바뀝니다

다만 이 편리함 뒤에 있는 원리는 꼭 이해하고 써야 해요. git 커밋의 ID, 그러니까 해시가 뭐냐면, 코드 내용과 메시지, 작성자, 날짜, 그리고 부모 커밋의 해시까지 몽땅 넣고 계산한 일종의 지문이에요. 그래서 메시지 한 글자만 바꿔도 그 커밋의 해시가 바뀌고, 부모의 해시가 바뀌었으니 그 뒤에 오는 모든 커밋의 해시도 도미노처럼 전부 바뀌어요. 겉보기엔 메시지만 고친 것 같지만 사실은 그 지점 이후의 히스토리를 통째로 새로 만든 거죠. 이미 원격에 푸시해서 동료와 공유한 브랜치에서 이 작업을 하면 강제 푸시(force push)가 필요해지고, 동료의 로컬 히스토리와 어긋나면서 팀 전체가 꼬일 수 있어요. 그래서 원칙은 명확해요. 아직 푸시하지 않은 로컬 커밋에만 쓰고, 공유된 브랜치라면 반드시 팀과 합의한 뒤에 하고, 푸시할 때도 --force 대신 --force-with-lease(내가 모르는 새 커밋이 원격에 있으면 푸시를 거부해 주는 안전장치)를 쓰는 거예요.

기존 도구들과의 위치

히스토리 편집 도구는 이미 여럿 있어요. git rebase -i는 표준이지만 러닝커브가 있고, git filter-repo는 저장소 전체를 대상으로 한 대규모 재작성에 강력하지만 명령줄 중심이라 진입장벽이 있죠. IntelliJ 계열 IDE의 rebase GUI나 lazygit 같은 터미널 UI 도구도 커밋 편집을 돕고요. git-knife는 그중에서 여러 커밋의 메타데이터를 한눈에 보고 일괄 편집한다는 좁고 명확한 문제를, 표라는 누구에게나 익숙한 UI로 풀었다는 게 포인트예요. 거창한 만능 도구라기보다, 특정 상황에서 확실히 편한 칼 한 자루인 셈이죠.

실무에서 쓸 만한 장면들

당장 떠오르는 활용처는 두 가지예요. 하나는 오픈소스에 PR을 보내기 전 커밋 메시지를 프로젝트 컨벤션에 맞게 다듬는 작업이고, 다른 하나는 회사 이메일과 개인 이메일이 섞여 버린 커밋을 정리하는 일이에요. 참고로 이메일 섞임은 사후 수정보다 예방이 나은데, gitconfig의 includeIf 기능으로 디렉터리별로 다른 이메일이 적용되게 해 두면 원천 차단이 돼요. 한 가지 더, 날짜 편집 기능은 커밋 시각을 마음대로 바꿀 수 있다는 뜻이라, 컨트리뷰션 그래프 이른바 잔디를 꾸며내는 데 악용될 여지도 있어요. 뒤집어 말하면, 커밋 날짜라는 건 애초에 신뢰할 수 있는 증거가 아니라는 걸 이해하는 게 진짜 교훈이에요.

정리하면, git-knife는 히스토리 재작성이라는 예리한 작업에 편한 손잡이를 달아 준 도구예요. 편해진 만큼 원리를 알고 써야 안전하고요. 여러분은 커밋 히스토리를 어느 쪽으로 다루세요? '기록이니 손대지 않는다' 파인가요, 아니면 '읽는 사람을 위해 다듬는다' 파인가요?