빠른 비교

git switch feature/login
git fetch origin
git rebase origin/main

# 충돌이 없으면 완료, 충돌 시
# 해결 후 git add <file>
# git rebase --continue

갈리는 기준

어떤 히스토리 정리 방식을 먼저 떠올리면 되나

rebase는 커밋 객체를 새로 만든다 — 해시가 바뀌는 이유가 여기 있다

Git의 commit 객체는 부모 커밋 해시, 트리 해시, 작성자, 타임스탬프를 포함해 SHA-1로 식별된다. git rebase origin/main을 실행하면 내 브랜치의 커밋들이 새로운 부모(최신 main 끝) 위에 재배치되는데, 부모 해시가 달라지므로 커밋 내용이 동일해도 해시가 완전히 바뀐다. 이 점이 rebase와 merge의 근본적인 차이다. merge는 기존 커밋 객체를 그대로 두고 새 merge commit을 추가하지만, rebase는 커밋 객체 자체를 다시 쓴다. "내용이 같으니 같은 커밋"이라는 생각은 Git 객체 모델에서 성립하지 않는다.

rebase가 히스토리를 직선으로 만들지만 공유 브랜치에서는 위험하다

rebase 후 히스토리는 마치 feature 브랜치가 항상 최신 main에서 출발한 것처럼 직선으로 보인다. PR을 병합하기 전 "작업을 깔끔하게 정리"하는 용도로 적합하다. 그러나 이미 다른 사람이 git pull해서 기반으로 삼은 공유 브랜치를 rebase하면 그 사람의 로컬 히스토리와 원격이 분기된다. 강제로 git push --force를 하면 협업자가 같은 변경을 중복으로 받거나 히스토리가 꼬인다. 핵심 규칙은 단순하다: "내가 소유한(혼자 작업 중인) 브랜치에만 rebase한다."

merge와 rebase 중 어느 쪽을 선택할지는 히스토리 목적에 달려 있다

merge는 두 브랜치가 합쳐진 시점과 경로를 히스토리에 그대로 보존한다. 협업 이력을 정직하게 남기는 관점에서 유리하고, 공유 브랜치를 안전하게 통합한다. rebase는 히스토리를 선형으로 정리해 git log와 git bisect 결과를 읽기 쉽게 만든다. git bisect는 히스토리가 직선일수록 이진 탐색이 더 정확하게 동작하므로 버그 원인 추적에 유리하다. 실무에서 많이 쓰는 패턴은 "개인 작업 브랜치에서는 rebase로 정리, PR merge는 merge commit 또는 squash merge로 통합"이다. 팀이 어떤 전략을 따르는지 먼저 확인하고 맞추는 것이 개인 선호보다 중요하다.

# 개인 브랜치 정리
git fetch origin
git rebase origin/main

# 공유 브랜치 통합
git fetch origin
git merge origin/main

rebase 중 충돌은 커밋 수만큼 반복될 수 있다

rebase는 커밋을 하나씩 재배치하기 때문에, 충돌이 여러 커밋에 걸쳐 발생할 수 있다. 각 커밋마다 충돌을 해결하고 git rebase --continue를 실행해야 한다. 중간에 무언가 이상해지면 git rebase --abort로 rebase 시작 전 상태로 안전하게 되돌아갈 수 있다. rebase 전에 git reflog나 임시 태그로 현재 브랜치 위치를 기록해 두면 만약의 복구 상황에 유리하다. 원격에 강제 push가 필요할 때는 --force 대신 --force-with-lease를 써서 다른 사람의 커밋을 덮어쓰는 사고를 방지한다.

git rebase origin/main
# ...
git push --force

# 이미 누군가가 같은 브랜치에 새 commit을 올렸다면
# 원격 ref를 덮어써 협업자 히스토리를 꼬이게 만들 수 있음

선택 기준

주의할 점