빠른 흐름

# 고칠 대상 커밋 확인
git log --oneline

# 대상 커밋에 붙일 fixup 커밋 생성
git add src/auth.js
git commit --fixup=a1b2c3d

# 대상 커밋 이후 범위를 대화형 rebase로 정리
git rebase -i --autosquash origin/main

# 원격 개인 브랜치 갱신
git push --force-with-lease

정리 방식

--fixup=<commit>은 대상 커밋 제목을 참조하는 fixup! 커밋을 만듭니다. 이후 git rebase -i --autosquash <base>를 실행하면 Git이 해당 커밋을 대상 커밋 바로 아래로 옮기고 todo 항목을 fixup으로 바꿉니다. 최종 히스토리에는 고친 내용이 대상 커밋 안으로 들어가고 fixup 커밋 자체는 남지 않습니다.

a1b2c3d Add login validation
b4c5d6e Add profile page
c7d8e9f fixup! Add login validation

git rebase -i --autosquash origin/main

--squash=<commit>은 대상 커밋에 합치되 메시지 편집을 남깁니다. 단순 오타 수정이나 누락 파일 추가처럼 메시지를 건드릴 필요가 없으면 fixup이 빠르고, 새 내용이 대상 커밋 메시지에도 반영되어야 한다면 squash가 맞습니다.

git commit --fixup=a1b2c3d   # 메시지 변경 없이 합침
git commit --squash=a1b2c3d  # 메시지 편집 기회를 남김

언제 쓸까

PR 리뷰에서 "첫 번째 커밋의 테스트도 같이 수정해 주세요" 같은 피드백을 받았을 때 유용합니다. 새 커밋을 계속 쌓아 두면 리뷰 흐름은 보이지만 최종 병합 전 히스토리가 산만해집니다. fixup 커밋으로 의도를 표시해 두면 리뷰 중에는 변경을 분리해 보여 줄 수 있고, 병합 전에는 대상 커밋 안으로 정리할 수 있습니다.

git add tests/auth.test.js
git commit --fixup=HEAD~2

기능 브랜치를 작은 논리 커밋으로 정리할 때도 적합합니다. 예를 들어 "API 추가", "UI 연결", "테스트 추가" 세 커밋 중 API 커밋에 빠진 타입 수정이 생기면 새 독립 커밋으로 남기는 대신 API 커밋에 대한 fixup으로 표시합니다.

rebase 범위

git rebase -i --autosquash <base>에서 <base>는 정리하려는 커밋들의 바로 이전 기준점입니다. 보통 PR 브랜치라면 origin/main 또는 브랜치를 딴 기준 커밋을 사용합니다. 범위가 너무 좁으면 대상 커밋이 rebase todo에 포함되지 않아 fixup이 적용되지 않고, 범위가 너무 넓으면 관련 없는 오래된 커밋까지 편집 대상에 들어갑니다.

git merge-base HEAD origin/main
git rebase -i --autosquash origin/main

todo 목록이 열리면 자동 배치가 맞는지 확인합니다. fixup! 커밋이 대상 커밋 바로 아래에 있고 명령이 fixup으로 바뀌어 있으면 의도대로 잡힌 것입니다.

주의할 점

fixup 대상은 커밋 제목으로도 매칭되지만, 제목이 비슷한 커밋이 많으면 혼동될 수 있습니다. 가능하면 커밋 SHA를 지정해 대상 커밋을 분명히 하는 편이 안전합니다.

git log --oneline --decorate
git commit --fixup=a1b2c3d