beautifulsoups.dev
Published on

Git rebase 후 PR 커밋 폭증? autosquash+fixup 정리법

Authors

서로 다른 작업 브랜치가 얽힌 상태에서 git rebase를 한 번 잘못 돌리면, GitHub PR 화면에 커밋이 폭증하거나(중복 커밋처럼 보이거나), 리뷰 단위가 산산조각나서 PR이 읽기 어려워지는 일이 흔합니다. 이 글에서는 왜 이런 현상이 생기는지를 먼저 짚고, 그 다음에 fixup!/squash! + --autosquash로 커밋을 “의도대로” 접는 정리 루틴을 소개합니다.

이미 강제 푸시까지 해버렸고 PR을 안전하게 되돌려야 한다면, 아래 글의 절차가 더 직접적입니다.

PR 커밋이 폭증하는 대표 원인 3가지

1) PR의 base(branch)와 rebase 대상이 어긋남

PR은 보통 feature -> main 형태입니다. 그런데 로컬에서 다음처럼 다른 기준으로 rebase하면 PR에 포함되는 커밋 범위가 바뀝니다.

  • PR base는 main인데
  • 로컬에서 release 또는 오래된 origin/main을 기준으로 rebase

그러면 GitHub가 “이 PR에 포함된 커밋”을 다시 계산하면서, 원래 PR에 없던 커밋들이 한꺼번에 딸려 들어온 것처럼 보일 수 있습니다.

2) rebase 중 merge 커밋/중복 cherry-pick이 섞임

merge 커밋이 있는 브랜치를 rebase하거나, 같은 커밋을 cherry-pick으로 다시 얹은 뒤 rebase하면 패치가 유사한 커밋이 여러 개 생길 수 있습니다. Git은 커밋 SHA 기준으로는 전혀 다른 커밋으로 인식하므로 PR 목록이 늘어납니다.

3) “작은 수정 커밋”이 누적된 상태에서 rebase

리뷰 반영을 fix typo, lint, oops 같은 커밋으로 계속 쌓아두면, rebase 후에도 그 커밋들이 그대로 남아 PR이 길어집니다. 이 케이스는 오히려 정리만 하면 해결됩니다.

이 글의 핵심은 3) 같은 상황에서 fixup/squash를 “의도적으로” 사용해 PR 커밋을 정돈하는 방법입니다.

해결 전략: fixup/squash + autosquash로 “리뷰 단위”로 접기

Git의 인터랙티브 리베이스는 강력하지만, 커밋이 많아질수록 reword/squash/fixup를 수동으로 편집하는 게 번거롭습니다. 이때 fixup! 또는 squash! 접두사를 커밋 메시지에 붙여두면, --autosquash가 자동으로 올바른 위치로 이동시키고 해당 커밋을 fixup/squash로 지정해줍니다.

  • fixup! 대상커밋제목 : 대상 커밋에 합치되 커밋 메시지는 버림
  • squash! 대상커밋제목 : 대상 커밋에 합치며 메시지 편집 기회 제공

일반적으로 리뷰 반영/자잘한 수정은 fixup!이 가장 깔끔합니다.

실전 시나리오: PR에 “리뷰 반영 커밋”이 20개 쌓였다

가정:

  • PR 브랜치: feature/payment
  • base: main
  • 목표: 논리 단위 커밋 3~5개만 남기고 나머지는 정리

1) 현재 PR이 어떤 커밋을 포함하는지 먼저 확인

git fetch origin

git log --oneline --decorate --graph origin/main..HEAD

origin/main..HEAD 범위가 “PR에 포함될 커밋”의 대략적인 집합입니다.

2) 자잘한 수정 커밋을 fixup으로 만들기

예를 들어, 원래 커밋이 아래와 같다고 합시다.

  • a1b2c3d Add payment request validation

리뷰 반영으로 파일을 조금 고쳤다면, 그 변경을 스테이지하고 다음처럼 커밋합니다.

git add -p

git commit --fixup a1b2c3d

그러면 커밋 메시지가 자동으로 fixup! Add payment request validation 형태로 만들어집니다.

이미 만들어둔 커밋 메시지를 나중에 fixup으로 바꾸고 싶다면 --fixup 대신 메시지를 직접 수정해도 됩니다.

git commit -m "fixup! Add payment request validation"

3) autosquash로 인터랙티브 리베이스 실행

여기서 핵심은 rebase 범위를 올바르게 잡는 것입니다. 보통은 base 브랜치(origin/main) 기준으로 잡습니다.

git rebase -i --autosquash origin/main

그러면 편집기가 열리며, Git이 fixup! ... 커밋을 자동으로 대상 커밋 바로 아래로 옮기고 fixup으로 표시해둡니다.

예시(편집기 화면 개념):

pick  a1b2c3d Add payment request validation
fixup d4e5f6a fixup! Add payment request validation
pick  1122334 Add payment service integration
fixup 2233445 fixup! Add payment service integration
pick  3344556 Add tests

저장 후 종료하면, fixup들이 자동으로 접히면서 커밋 수가 줄어듭니다.

4) 충돌이 나면 “해결 → continue” 반복

# 충돌 해결
# ... 파일 수정 ...

git add <resolved-files>
git rebase --continue

정리 목적이라면 충돌이 나도 대부분 “최종 코드 상태가 맞는지”만 확인하면 됩니다.

5) PR 브랜치에 반영(대부분 강제 푸시 필요)

rebase는 커밋 SHA를 바꾸므로 원격 브랜치와 히스토리가 달라집니다. 이때 안전 장치가 있는 강제 푸시 옵션을 권장합니다.

git push --force-with-lease origin feature/payment
  • --force보다 안전합니다.
  • 원격에 누군가가 추가 푸시한 경우, 내 로컬이 그걸 모르면 푸시가 거절됩니다.

“이미 만들어진 커밋”을 fixup 대상으로 빠르게 지정하는 팁

방법 A) 커밋 해시를 지정해 fixup 커밋 만들기

앞서 본 git commit --fixup <hash>가 가장 정확합니다.

방법 B) 대상 커밋을 찾기 쉽게: 커밋 제목을 안정적으로 유지

fixup! <대상 커밋 제목>은 제목 문자열 매칭에 의존합니다. 대상 커밋 제목을 중간에 바꾸면 autosquash가 기대대로 못 붙일 수 있습니다.

  • 대상 커밋을 reword로 바꿔야 한다면
  • fixup들을 먼저 다 접고(rebase)
  • 마지막에 커밋 제목을 정리하는 순서가 안전합니다.

PR 커밋 폭증을 예방하는 운영 규칙

1) 리뷰 반영은 기본적으로 fixup으로 쌓기

리뷰 코멘트 반영을 “별도 의미 있는 변경”으로 남길 게 아니라면:

  • fixup으로 쌓아두고
  • PR 머지 직전(또는 리뷰 완료 시점)에 autosquash로 정리

이 습관만으로 PR 품질이 크게 좋아집니다.

2) rebase 범위는 항상 origin/<base>로

로컬 main이 최신이라는 보장이 없으면, 다음처럼 원격을 기준으로 잡는 게 덜 위험합니다.

git fetch origin

git rebase -i --autosquash origin/main

3) 강제 푸시는 --force-with-lease로

히스토리를 바꾸는 작업(rebase, amend, autosquash)은 강제 푸시가 필요할 때가 많습니다.

git push --force-with-lease

팀 작업에서 “내가 모르는 원격 변경”을 덮어쓰는 사고를 줄이는 최소한의 안전벨트입니다.

자주 겪는 함정과 체크리스트

autosquash를 했는데 커밋이 안 접힌다

  • --autosquash 옵션을 빼먹었는지 확인
  • 커밋 메시지가 정확히 fixup! <대상제목> 또는 squash! <대상제목>인지 확인
  • 대상 커밋이 rebase 범위 안에 포함되는지 확인(가장 흔한 원인)

rebase 범위를 헷갈리면 다음 명령으로 기준 커밋을 잡는 것도 방법입니다.

# main과 feature가 갈라진 지점(merge-base)을 기준으로 i-rebase
BASE=$(git merge-base HEAD origin/main)
git rebase -i --autosquash $BASE

PR에 커밋이 폭증했는데, 사실은 base branch가 바뀐 경우

GitHub에서 PR base를 main에서 develop으로 바꾸면 포함 커밋이 확 달라질 수 있습니다. PR 설정에서 base가 올바른지부터 확인하세요.

이미 force push 했고 PR이 꼬였다

정리(rebase/autosquash) 자체는 좋은데, 이미 PR이 이상해졌다면 “복구 절차”가 필요합니다. 아래 글의 7단계가 실전에서 도움이 됩니다.

정리: 커밋 폭증은 “정리되지 않은 히스토리”가 드러난 것

PR 커밋 폭증은 종종 rebase의 부작용처럼 보이지만, 많은 경우는 리뷰 반영 커밋이 누적된 히스토리가 rebase 이후 더 선명하게 드러난 결과입니다. fixup!/squash!로 의도를 표시해두고, git rebase -i --autosquash <base>로 자동 정리하는 루틴을 팀 규칙으로 만들면:

  • PR 커밋이 논리 단위로 유지되고
  • 리뷰가 빨라지며
  • 머지 후 히스토리도 깔끔해집니다.

필요한 최소 명령만 다시 적으면 아래 3줄이 핵심입니다.

git commit --fixup <target-commit>
git rebase -i --autosquash origin/main
git push --force-with-lease
Discuss on Twitter • View on GitHub