Git history 명령어 완전 정리: 과거 커밋 수정부터 브랜치 자동 재구성까지

Git 이력 편집이 어려웠던 이유와 git history의 등장

Git을 사용하다 보면 이미 생성한 커밋을 수정해야 하는 상황이 자주 발생합니다. 작은 오타를 수정하거나, 커밋 메시지를 변경하거나, 하나의 커밋을 둘로 나누고 싶은 경우가 대표적입니다.

기존 Git에서도 이러한 작업은 rebase -i, commit --fixup, autosquash 등의 기능을 활용하면 가능했습니다. 하지만 여러 브랜치가 연결되어 있는 프로젝트에서는 작업 과정이 복잡해지고, 리베이스 도중 작업 트리가 불완전한 상태가 되는 등 관리가 쉽지 않았습니다.

Git 2.54와 Git 2.55에서 실험적으로 추가된 git history 명령어는 이러한 불편함을 개선하기 위해 등장했습니다. 기존 Git 작업 방식을 유지하면서도 과거 커밋 수정과 파생 브랜치 재구성을 자동화하여 보다 안전하고 간편하게 이력을 관리할 수 있도록 지원합니다.

이번 글에서는 git history의 개념과 주요 기능인 fixup, reword, split 명령을 중심으로 특징과 활용 방법을 살펴보겠습니다.

반응형

---

Git history란?

git history는 Git 코어에 포함된 실험적(Experimental) 기능입니다.

별도의 Git 확장 프로그램이나 외부 도구를 설치하지 않아도 사용할 수 있으며, 기존 Git에서 복잡했던 이력 수정 작업을 더욱 단순하게 수행할 수 있도록 설계되었습니다.

Git 버전별 추가 기능은 다음과 같습니다.

• Git 2.54
  • reword
  • split
• Git 2.55
  • fixup

현재 git history는 다음 세 가지 하위 명령으로 구성됩니다.

• fixup
• reword
• split

---

기존 Git 이력 수정 방식의 한계

기존 Git에서는 과거 커밋을 수정하기 위해 다음과 같은 작업을 수행해야 했습니다.

• Interactive Rebase(git rebase -i)
• git commit --fixup
• autosquash
• 브랜치 이동 및 재정렬

특히 여러 기능 브랜치가 하나의 커밋을 기반으로 생성되어 있는 경우에는 다음과 같은 어려움이 발생합니다.

• 여러 브랜치를 오가며 작업해야 한다.
• 리베이스 중 충돌이 발생할 수 있다.
• 작업 트리가 중간 상태로 남을 수 있다.
• 파생 브랜치까지 직접 다시 정리해야 한다.

이러한 이유로 Git 대안인 jj가 자주 언급되기도 했지만, 기존 Git 사용자가 새로운 작업 방식에 적응하기는 쉽지 않았습니다.

git history는 이러한 문제를 기존 Git 환경 안에서 해결하는 것을 목표로 합니다.

---

git history fixup : 과거 커밋 수정과 브랜치 자동 갱신

가장 주목할 만한 기능은 **fixup**입니다.

기존에는 오래된 커밋 하나를 수정하면 이후 커밋과 관련 브랜치도 직접 다시 정리해야 했습니다.

git history fixup은 이러한 과정을 자동으로 처리합니다.

동작 과정은 다음과 같습니다.

1. 수정할 내용을 스테이징한다.
2. 대상 커밋을 지정한다.
3. 수정 내용을 해당 커밋에 합친다.
4. 이후 커밋을 모두 다시 생성한다.
5. 해당 커밋에서 파생된 모든 로컬 브랜치를 새로운 커밋으로 자동 이동시킨다.

사용 예시

git add .
git history fixup <commit>

기존의

git commit --fixup
git rebase --autosquash

과 유사한 역할을 수행하지만, 가장 큰 차이점은 파생된 로컬 브랜치까지 함께 갱신한다는 것입니다.

예를 들어 다음과 같은 구조가 있다고 가정해보겠습니다.

A
└── B
     └── C
          └── D

여기서 B를 수정하면

A
└── B*
     └── C*
          └── D*

처럼 새로운 커밋들이 자동으로 생성되며, feat-1, feat-2와 같은 관련 브랜치도 새로운 커밋을 가리키도록 함께 이동합니다.

필요하다면 갱신 범위를 현재 브랜치로 제한하는 것도 가능합니다.

---

원자적 처리로 안전한 이력 수정

git history의 세 가지 명령은 모두 원자적(Atomic) 으로 동작합니다.

즉,

• 작업 도중 중간 상태를 남기지 않고
• 충돌 가능성이 있는 작업은 애초에 실행하지 않습니다.

덕분에 작업 트리가 절반만 수정된 상태로 남는 상황을 방지할 수 있습니다.

다만 이러한 안정성을 위해 몇 가지 제한도 존재합니다.

대표적으로 병합(Merge) 커밋이 포함된 이력에서는 동작하지 않습니다.

이는 이력 재작성이 복잡한 상태 관리 문제로 이어지는 것을 방지하기 위한 설계입니다.

---

git history reword : 커밋 메시지만 변경하기

개발을 진행하다 보면 코드 구조가 바뀌면서 예전 커밋 메시지가 더 이상 적절하지 않은 경우가 있습니다.

이럴 때 사용하는 명령이 reword입니다.

사용 방법

git history reword <commit>

명령을 실행하면 기존 커밋 메시지가 편집기에 열립니다.

메시지를 수정하여 저장하면

• 해당 커밋이 새 해시를 갖게 되고
• 이후 커밋과 브랜치가 자동으로 재구성됩니다.

reword의 가장 큰 특징은 작업 트리나 인덱스를 전혀 변경하지 않는다는 점입니다.

즉,

• 코드 변경 없이
• 커밋 그래프만 수정합니다.

또한 체크아웃하지 않은 브랜치의 커밋도 현재 작업을 방해하지 않고 수정할 수 있습니다.

---

git history split : 하나의 커밋을 둘로 나누기

하나의 커밋 안에 서로 관련 없는 변경 사항이 함께 들어가는 경우가 있습니다.

이럴 때 사용하는 기능이 split입니다.

사용 방법

git history split <commit>

명령을 실행하면 변경 내용이 헝크(Hunk) 단위로 표시됩니다.

사용자는 각 변경을 선택하여

• 첫 번째 커밋에 포함할 내용
• 두 번째 커밋에 포함할 내용

을 직접 지정할 수 있습니다.

결과적으로

B

라는 하나의 커밋은

B1
B2

두 개의 커밋으로 분리되고,

그 이후의 커밋 역시 새로운 이력에 맞게 자동으로 다시 생성됩니다.

기존에는 git add -p와 Interactive Rebase를 조합해야 했던 작업을 하나의 명령으로 수행할 수 있다는 점이 큰 장점입니다.

---

git history와 jj의 차이점

git history는 Git 사용성을 크게 개선하지만, jj를 완전히 대체하는 것은 아닙니다.

jj는 다음과 같은 기능을 제공합니다.

• 작업 로그 기반 실행 취소
• 작업 복사본을 커밋으로 모델링
• 리베이스 중 충돌 상태 유지
• 충돌을 1급 객체로 관리

반면 git history는 Git의 기존 작업 방식을 유지하면서 다음 기능을 제공합니다.

• 과거 커밋 수정
• 커밋 메시지 변경
• 커밋 분할
• 파생 브랜치 자동 갱신
• 원자적 이력 재작성

즉, jj의 일부 장점을 Git 사용자들이 별도 도구 없이 활용할 수 있도록 제공하는 것이 핵심입니다.

---

git history의 장점과 현재 한계

장점

• Git 기본 배포판에 포함된 실험적 기능
• 별도 설치 없이 사용 가능
• 과거 커밋 수정 자동화
• 파생 브랜치 자동 재구성
• 커밋 메시지 변경 지원
• 커밋 분할 기능 제공
• 원자적 처리로 안정성 확보

한계

• 실험적 기능이다.
• 병합 커밋이 있는 이력에서는 사용할 수 없다.
• jj 수준의 충돌 관리 기능은 제공하지 않는다.
• 작업 로그나 실행 취소 기능은 포함되어 있지 않다.

---

728x90

git history는 Git에서 가장 번거로웠던 이력 수정 작업을 크게 단순화하는 실험적 기능입니다. 특히 fixup, reword, split 명령은 기존에 여러 Git 명령을 조합해야 했던 과정을 하나의 명령으로 수행할 수 있도록 개선했으며, 파생 브랜치까지 자동으로 재구성해 작업 부담을 줄여줍니다.

물론 아직은 병합 커밋을 지원하지 않는 등 제약이 있으며, jj와 같은 차세대 버전 관리 도구가 제공하는 고급 기능까지 모두 포함하고 있지는 않습니다. 그럼에도 별도의 도구를 설치하지 않고 Git 환경 안에서 이력 편집 기능을 확장할 수 있다는 점은 큰 의미가 있습니다.

향후 Git 릴리스에서 기능이 더욱 발전한다면, 복잡한 이력 수정 작업도 지금보다 훨씬 안전하고 효율적으로 수행할 수 있을 것으로 기대됩니다.

300x250

https://lalitm.com/post/git-history/

The git history command deserves more attention