git range-diff: 리베이스 전후 커밋을 짝지어 비교하기

지난 글에서 흩어진 작성자 신원을 .mailmap으로 통합하는 방법을 다뤘다. 이번에는 히스토리를 다시 쓴 뒤 무엇이 바뀌었는지 확인하는 도구를 살펴본다. 인터랙티브 리베이스로 커밋을 정리하거나 --amend로 메시지를 고친 다음, “내가 의도한 변경만 일어났을까?”를 확인하고 싶을 때가 있다. 일반 git diff는 두 트리의 최종 상태만 비교하므로 “커밋 3개를 어떻게 다듬었는지”는 보여 주지 못한다. 바로 이 간격을 메우는 도구가 git range-diff다.

range-diff가 푸는 문제

리베이스를 하면 커밋의 SHA가 전부 바뀐다. 부모가 달라지면 같은 패치라도 새로운 해시를 얻기 때문이다. 그래서 “리베이스 전 a1b2c3와 리베이스 후 7c6d5e가 같은 작업인가?”를 사람이 해시만 보고 판단하긴 어렵다.

git range-diff는 두 커밋 범위를 받아 비슷한 커밋끼리 짝을 지은 뒤, 각 짝의 패치 내용 차이를 보여 준다. 해시가 달라도 같은 작업 단위를 알아서 묶어 주는 것이 핵심이다.

기본 사용법

세 가지 형태로 호출할 수 있다.

# 1) 두 범위를 명시
git range-diff main..old-feature main..new-feature

# 2) 세 점 축약형 (공통 베이스가 같을 때)
git range-diff old-feature...new-feature

# 3) 리베이스 직후 reflog를 활용
git range-diff @{u} @{1} @

가장 자주 쓰는 건 리베이스나 amend 직후의 검토다. ORIG_HEAD는 위험한 작업 직전의 위치를 가리키므로, 다음 한 줄이면 방금 다시 쓴 결과를 곧바로 비교할 수 있다.

# 리베이스 직후: 다시 쓰기 전(ORIG_HEAD)과 지금(HEAD)을 비교
git range-diff ORIG_HEAD...HEAD

출력 기호 읽는 법

출력의 각 줄은 왼쪽번호: old해시 기호 오른쪽번호: new해시 제목 형태다. 가운데 기호가 두 커밋의 관계를 나타낸다.

기호	의미
=	두 커밋이 완전히 동일 (패치 변화 없음)
!	짝은 맞지만 내용이 달라짐 (아래에 변경 diff 표시)
<	new 범위에만 있는 커밋 (추가됨)
>	old 범위에만 있던 커밋 (사라짐)

!로 표시된 커밋 아래에는 “diff의 diff”가 붙는다. 즉 이전 패치와 새 패치가 어떻게 달라졌는지를 보여 준다. 빨간 줄(-)은 예전 패치에 있던 내용, 초록 줄(+)은 새 패치에 들어간 내용이다. 메시지만 고쳤다면 @@ 헤더 없이 제목 줄만 바뀐 것으로 나온다.

실전 1: 강제 푸시 전 안전 점검

--force-with-lease로 브랜치를 덮어쓰기 직전, “내가 정말 의도한 것만 바꿨는지” 확인하는 습관은 사고를 크게 줄여 준다.

# 원격 추적 브랜치와 현재 브랜치를 비교
git range-diff origin/feature...feature

여기서 <나 >로 예상치 못한 커밋이 사라지거나 추가됐다면, 리베이스 중 실수로 커밋을 누락하거나 중복시킨 신호다. 출력이 전부 =와 의도한 !로만 채워졌다면 안심하고 푸시해도 된다.

실전 2: 코드 리뷰 v1 vs v2

리뷰어가 첫 버전에 코멘트를 남기고, 작성자가 리베이스로 커밋을 다듬어 다시 올리는 경우를 생각해 보자. 리뷰어는 “지난번 대비 무엇이 바뀌었나”가 궁금하다. 이때 두 버전의 태그를 비교하면 깔끔하다.

# 작성자가 각 제출본에 태그를 달아 두면
git tag pr-v1 feature        # 첫 제출 시점
# ... 리뷰 후 리베이스 ...
git range-diff pr-v1...feature

!로 표시된 커밋과 그 아래 diff만 보면, 리뷰 코멘트가 실제로 반영됐는지 한눈에 확인할 수 있다. 전체를 다시 읽지 않아도 되므로 리뷰 라운드가 빨라진다.

비교 정밀도 조절

짝짓기가 어긋날 때는 --creation-factor로 “얼마나 비슷해야 같은 커밋으로 볼지”를 조절한다. 기본값은 60이며, 값을 높이면 더 관대하게 짝을 짓는다.

# 커밋을 크게 재구성해 짝짓기가 흐트러질 때
git range-diff --creation-factor=90 ORIG_HEAD...HEAD

공백 변화를 무시하려면 git diff와 동일하게 --ignore-space-change(-b)를 붙일 수 있다.

git range-diff는 히스토리를 다시 쓰는 모든 작업의 안전망이다. 리베이스·amend·cherry-pick으로 커밋을 손본 뒤 강제 푸시하기 전에 ORIG_HEAD...HEAD 한 줄만 습관처럼 실행해도, “의도하지 않은 변경”을 푸시하는 사고를 거의 막을 수 있다. 다음 글부터는 이렇게 다시 쓰기 전후를 확인하는 데서 나아가, 실제로 잘못된 커밋을 되돌리는 구체적인 상황들을 하나씩 다룬다.

---

지난 글: git mailmap: 흩어진 작성자 신원을 하나로 통합하기

다음 글: 마지막 커밋 되돌리기: amend · reset · revert 골라 쓰기

읽어주셔서 감사합니다. 😊