Quick Comparison

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

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

갈리는 기준

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

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

Git commit은 부모 commit ID, tree ID, 작성자, 시간, message를 포함하며 object format에 따라 식별됩니다. git rebase origin/main은 내 branch의 commit을 새로운 부모 위에 다시 적용하므로, 내용이 같아도 parent가 달라 새 commit ID가 만들어집니다. merge는 기존 commit을 유지하고 필요할 때 merge commit을 추가하지만, rebase는 history를 다시 씁니다.

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

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

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

merge는 두 branch가 합쳐진 시점과 경로를 history에 남기며 shared branch 통합에 적합합니다. rebase는 linear history를 만들어 review·log·rollback 단위를 읽기 쉽게 할 수 있습니다. git bisect는 merge를 포함한 DAG에서도 탐색하므로 linear history가 정확성을 보장하는 것은 아니며, 재현 가능한 good/bad 판정이 핵심입니다. 팀의 merge/rebase/squash policy를 먼저 따르는 것이 개인 선호보다 중요합니다.

# 개인 브랜치 정리
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-with-lease

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

선택 기준

주의할 점