git rebase를 쓰기 전에 챙기는 것들

git rebase를 처음 쓸 때 가장 겁나는 건 "history를 다시 쓴다"는 말이다. 실제로 잘못 쓰면 팀원이 push를 못 하거나 커밋이 꼬이는 상황이 생긴다. 쓰기 전에 확인하는 기준 몇 가지를 정리해봤다.

혼자 쓰는 브랜치인지 확인한다

rebase의 핵심 위험은 공유 브랜치에서 history를 재작성하면 다른 사람의 작업 기반이 달라진다는 것이다.

git log --oneline origin/feature/my-branch..HEAD

로컬에만 있는 커밋이라면 rebase를 해도 다른 사람에게 영향이 없다. 이미 push한 커밋을 rebase하면 force push가 필요하고, 그 시점에 다른 사람이 같은 브랜치를 체크아웃하고 있으면 문제가 생긴다.

main이나 develop 같은 공유 브랜치에는 rebase를 직접 하지 않는다.

현재 상태를 저장해둔다

rebase 중에 conflict가 많이 나거나 실수했을 때 돌아가기 위해 현재 커밋을 기록해둔다.

git tag backup-before-rebase

rebase가 꼬이면:

git rebase --abort          # rebase 진행 중일 때
git reset --hard backup-before-rebase  # 태그로 되돌리기

interactive rebase로 커밋 정리

PR 올리기 전에 WIP 커밋이나 오타 수정 커밋을 하나로 합치고 싶을 때 interactive rebase를 쓴다.

git rebase -i HEAD~3

에디터가 열리면 합칠 커밋을 s(squash)로 바꾼다.

pick abc1234 feat: add user filter
s   def5678 fix typo
s   ghi9012 wip: progress

squash는 커밋 메시지를 하나로 합친다. fixup을 쓰면 메시지 없이 바로 합친다. 결과적으로 깔끔한 커밋 하나가 남는다.

upstream 변경을 가져올 때

feature 브랜치에서 작업하는 동안 main에 새 커밋이 생겼을 때, merge 대신 rebase를 쓰면 히스토리가 선형으로 유지된다.

git fetch origin
git rebase origin/main

conflict가 나면 파일을 수정하고 git add한 뒤 git rebase --continue로 진행한다. 같은 파일이 여러 커밋에서 충돌나면 반복해서 해결해야 한다. 복잡해지면 git rebase --abort로 돌아가서 merge를 쓰는 게 나은 선택일 수 있다.