Git 커밋 기록을 표처럼 고치는 git-knife, 날짜와 작성자도 한 번에 바꿔요

Git 히스토리에서 오래된 이메일 주소나 잘못 적은 날짜를 고치려면 명령어와 환경변수를 조합해야 할 때가 많아요. git-knife는 커밋 메시지부터 작성자·커미터의 이름, 이메일, 날짜까지 표에서 직접 편집하게 만든 데스크톱 도구예요. 1
핵심 요약
| 구분 | 내용 |
| 편집 범위 | 커밋 메시지, 작성자·커미터 이름과 이메일, 작성일과 커밋일을 바꿀 수 있어요. |
| 일괄 작업 | 일반 문자열이나 정규표현식으로 여러 커밋의 텍스트 필드를 한 번에 치환해요. |
| 작동 방식 | 시스템에 설치된 Git CLI와 `git commit-tree`로 커밋을 다시 만들어요. 기존 tree를 재사용해 파일 내용은 유지해요. |
| 안전장치 | 적용 전 비교 화면, 자동 백업 ref, 원격에 올라간 기록 경고, 서명 손실 경고와 재서명 옵션을 제공해요. |
| 현재 범위 | 병합을 포함한 커밋 그래프 편집을 지원해요. 커밋 순서 변경, squash, drop과 브랜치·원격 관리는 아직 지원하지 않아요. |
1. 커밋 메타데이터 편집을 데스크톱 표로 옮겼어요
Git GUI는 보통 커밋 메시지를 고치거나 커밋 순서를 정리하는 데 집중해요. 과거 커밋의 작성자 이메일과 날짜, 커미터 정보를 여러 건 고치려면 `git-filter-repo`, rebase 환경변수, `git commit-tree` 같은 CLI 작업이 필요했어요. git-knife는 이 작업을 커밋 목록과 편집 칸이 있는 데스크톱 화면으로 옮겼어요. 2
저장소를 열면 원하는 로컬 브랜치를 checkout하지 않고 ref로 직접 읽어요. 현재 작업 중인 브랜치와 working tree를 그대로 둔 채 다른 로컬 브랜치의 기록을 편집할 수 있어요. 수정한 행은 화면에서 구분되고, 적용 전에 기존 값과 새 값을 비교할 수 있어요.
여러 커밋에 남은 예전 회사 이메일을 새 주소로 바꾸는 작업도 한 번에 처리해요. 대상 필드에서 작성자 이메일과 커미터 이메일을 고르고 문자열을 치환하면 돼요. 정규표현식과 캡처 그룹도 지원해서 이름이나 메시지의 일정한 패턴을 정리할 때 쓸 수 있어요.
파일 내용은 그대로 두고 커밋을 다시 만들어요
git-knife는 별도 Git 엔진을 구현하지 않아요. 시스템의 `git` 명령을 호출하고, 편집이 시작된 지점부터 커밋을 `git commit-tree`로 다시 만들어요. 각 커밋이 가리키던 tree를 재사용하므로 파일 내용은 바뀌지 않아요. 메타데이터가 달라지면 해당 커밋과 뒤에 이어지는 커밋의 해시는 새로 생겨요.
현재 저장소 설명에는 병합 구간을 포함한 전체 커밋 그래프 재작성이 지원된다고 적혀 있어요. 반면 커밋의 순서를 바꾸거나 합치고 삭제하는 기능은 개발 예정이에요. staging, 브랜치 생성, 원격 저장소 관리도 이 앱의 범위에 들어가지 않아요. 2
백업과 서명 경고를 함께 제공해요
히스토리를 적용하기 전에는 `refs/knife-backup/` 아래에 기존 브랜치 끝을 가리키는 백업 ref를 만들어요. 앱의 Backups 화면에서 복구하거나 Git CLI로 이전 상태를 다시 가리킬 수 있어요. 변경 비교와 복구 지점을 함께 제공해 실수했을 때 돌아갈 경로를 남겨요.
GPG 또는 SSH로 서명된 커밋은 해시가 바뀌면서 기존 서명이 무효가 돼요. git-knife는 원시 커밋의 `gpgsig` 헤더를 찾아 서명된 커밋을 표시해요. 재작성 과정에서 사라질 서명 개수를 경고하고, 설정된 키로 새 커밋에 다시 서명하는 옵션도 제공해요. 키가 없는데 재서명을 켜면 ref를 바꾸기 전에 작업을 중단해요.
원격 기록은 자동으로 바꾸지 않아요
git-knife가 수정하는 범위는 로컬 브랜치예요. 원격 저장소에 접속하거나 변경된 기록을 자동으로 push하지 않아요. 이미 공유된 커밋을 고치면 일반 push는 non-fast-forward로 거부되고, 사용자가 직접 `git push --force-with-lease`를 실행해야 해요.
`--force-with-lease`도 팀 협의를 대신하지는 못해요. 동료가 기존 기록을 받아 간 뒤라면 로컬 히스토리가 갈라져요. 오래된 작성자 정보를 정리할 때는 대상 브랜치와 변경 시점을 먼저 공유하고, 각자 작업 중인 커밋이 없는지 확인하는 편이 안전해요.
왜 중요한가요
커밋 메타데이터는 파일 내용만큼 자주 보지는 않지만, 기여자 통계와 변경 이력 추적에 쓰여요. 계정을 바꾸며 이메일이 달라졌거나 마이그레이션 과정에서 날짜가 틀어지면 여러 커밋을 같은 규칙으로 고쳐야 해요. git-knife는 수정 대상 선택, 일괄 치환, 변경 비교, 백업을 한 화면에 묶어 이런 일회성 정리 작업의 명령어 부담을 줄여요. 2
다만 편집 버튼을 누르는 과정이 쉬워져도 Git 히스토리 재작성 자체의 성질은 같아요. 커밋 해시가 바뀌고, 이미 공유한 브랜치라면 동료의 로컬 기록과 충돌할 수 있어요. 개인 브랜치나 아직 push하지 않은 기록에서 먼저 써 보고, 공유 브랜치는 변경 범위와 복구 방법을 정한 뒤 다루는 편이 좋아요.
참고 자료
- git-knife - Git 커밋 메타데이터를 표처럼 편집하는 데스크톱 GUI — GeekNews
- TheRealYT/git-knife — GitHub
'IT & AI' 카테고리의 다른 글
| AI 코딩 시대, 플랫폼 엔지니어링이 비용을 줄이는 이유 (0) | 2026.08.17 |
|---|---|
| Airbnb는 왜 로그인 방법을 서버가 고르게 했을까요 (0) | 2026.08.17 |
| 앱 밖 결제에도 15%, Apple이 꺼낸 새 수수료안 (1) | 2026.08.16 |
| AI에게 일을 잘 맡기려면 맥락과 검증이 먼저예요 (0) | 2026.08.16 |
| AI가 수학에서 강한 이유는 큰 작업 공간일 수 있어요 (0) | 2026.08.16 |