과거 커밋을 안전하게 고치는 git history, fixup·reword·split 사용법

과거 커밋을 안전하게 고치는 git history, fixup·reword·split 사용법

Git history 명령어 썸네일

과거 커밋 하나를 고치려다 `rebase -i`와 브랜치 정리에 시간을 쓴 경험이 있다면 `git history`를 살펴볼 만해요. Git 2.54와 2.55에 추가된 이 실험적 명령은 커밋 수정부터 후속 브랜치 재구성까지 한 번에 처리해요. 1

핵심 요약

명령	하는 일	확인할 점
`git history fixup`	스테이징한 변경을 과거 커밋에 합치고 후손 브랜치를 다시 구성해요	병합 커밋이 있는 이력에서는 쓸 수 없어요
`git history reword`	과거 커밋 메시지를 바꾸고 뒤따르는 커밋을 새 해시에 맞춰 만들어요	커밋 해시가 바뀌므로 공유 전 로컬 이력에 쓰는 편이 안전해요
`git history split`	한 커밋의 변경을 헝크 단위로 골라 두 커밋으로 나눠요	충돌 가능성이 있으면 작업을 시작하지 않아요

1. 대화형 리베이스의 자주 쓰는 작업을 명령 하나로 줄였어요

`git history`에는 `fixup`, `reword`, `split` 세 가지 하위 명령이 있어요. Git 2.54에서 `reword`와 `split`이 들어왔고, Git 2.55에서 `fixup`이 추가됐어요. 별도 도구를 설치하지 않아도 Git 코어 배포판 안에서 시험할 수 있다는 점이 실용적이에요. 아직 실험 단계라서 팀 표준 절차에 바로 넣기보다는 로컬 브랜치에서 동작과 제한을 먼저 확인하는 편이 좋아요. 2

fixup은 수정할 커밋과 후손 브랜치를 함께 갱신해요

먼저 고칠 내용을 `git add`로 스테이징해요. 이어서 `git history fixup `을 실행하면 변경분이 대상 커밋에 합쳐져요. 대상 커밋의 해시가 달라지므로 그 뒤에 놓인 커밋도 새로 만들어져요. 해당 커밋에서 갈라진 로컬 브랜치까지 새 커밋을 가리키도록 조정해 주는 점이 기존 `git commit --fixup`과 autosquash 조합보다 편해요.

모든 후손 브랜치를 바꾸고 싶지 않다면 갱신 범위를 현재 브랜치로 제한할 수 있어요. 오래된 기능 브랜치를 버전별로 보관하거나 여러 사람이 이미 공유한 이력을 다룬다면 기본 동작이 기대와 맞는지 먼저 확인해야 해요. 원격에 공개한 커밋을 다시 쓰면 다른 개발자의 브랜치와 충돌할 수 있다는 Git의 일반적인 주의점도 그대로 남아요.

728x90

reword는 작업 트리를 건드리지 않고 메시지만 바꿔요

`git history reword `을 실행하면 편집기에 기존 커밋 메시지가 열려요. 내용을 저장하면 Git이 후속 커밋과 관련 브랜치를 새 해시에 맞춰 다시 구성해요. 코드 내용은 그대로 두고 잘못 쓴 설명이나 지금의 설계와 맞지 않는 메시지만 고칠 때 쓸 수 있어요.

현재 체크아웃하지 않은 브랜치의 커밋도 다룰 수 있어요. 메시지를 바꾸려고 해당 브랜치로 이동하고 대화형 리베이스 목록을 편집하는 절차를 줄여 줘요. 인덱스와 작업 트리를 건드리지 않아서 진행 중인 수정과 섞일 여지도 적어요.

split은 뒤섞인 변경을 두 커밋으로 나눠요

`git history split `은 대상 커밋의 변경을 헝크 단위로 보여 줘요. 첫 번째 커밋에 남길 헝크를 고르면 나머지는 두 번째 커밋으로 들어가요. 그 위에 있던 후속 커밋과 브랜치도 분리된 두 커밋을 기준으로 다시 만들어져요.

서로 관계없는 수정이 한 커밋에 섞였을 때 특히 유용해요. 논리적 변경 단위가 나뉘면 코드 리뷰에서 의도를 따라가기 쉽고, 나중에 `git bisect`나 선택적 되돌리기를 사용할 때도 범위를 좁힐 수 있어요. 기존에는 `rebase -i`, 커밋 편집, 부분 스테이징을 이어서 처리해야 했지만 `split`은 이 과정을 한 명령 안에 묶어요.

충돌 가능성이 있으면 시작 전에 거부해요

세 하위 명령은 작업을 원자적으로 처리해요. 중간에 충돌이 날 수 있는 이력 재작성은 아예 시작하지 않아서 작업 트리가 절반만 바뀐 상태로 남지 않아요. 대신 병합 커밋이 포함된 이력에서는 동작하지 않아요. 충돌을 상태로 보존한 채 나중에 해결할 수 있는 `jj`보다 적용 범위가 좁은 이유예요. 3

이 제한은 안전성과 기능 범위를 맞바꾼 선택에 가까워요. 선형 로컬 브랜치를 정리할 때는 부담을 낮춰 주지만, 병합이 많은 저장소에서는 기존 리베이스 절차나 다른 도구가 필요해요. 실행 전에 `git log --graph --all`로 대상 커밋의 후손과 병합 여부를 확인하면 예상하지 못한 브랜치 재작성을 줄일 수 있어요.

왜 중요한가요

Git 이력 편집은 기능보다 절차가 어려운 경우가 많아요. 원하는 결과를 알고 있어도 대화형 리베이스 목록, 부분 스테이징, autosquash, 참조 갱신을 따로 조합해야 했어요. `git history`는 자주 쓰는 세 작업에 이름을 붙이고, 관련 로컬 브랜치의 갱신까지 한 번에 처리해요. 기존 Git 흐름을 유지하면서 이력 편집에 드는 명령 수를 줄일 수 있어요. 2

다만 실험적 명령이고 병합 커밋을 지원하지 않아요. 팀 저장소에서는 공유하지 않은 로컬 커밋부터 시험하고, 실행 전 브랜치 범위와 작업 트리 상태를 확인하는 편이 안전해요. `jj`의 작업 로그, 간단한 실행 취소, 충돌 보존 같은 기능까지 대체하지도 않아요. Git을 계속 쓰면서 과거 커밋을 자주 다듬는 개발자에게 선택지 하나가 더 생겼다고 보는 게 정확해요.

참고 자료

1. Git history 명령어는 더 많은 관심을 받을 자격이 있다 — GeekNews
2. The git history command deserves more attention — Lalit Maganti
3. git-history Documentation — Git