히스토리 정리

5. 자주 하는 실수 (Tip)

❌ 실수 1: 이미 push 한 브랜치를 rebase 한다

동료가 받아간 커밋의 해시가 바뀌어 동료 쪽에서 push 가 거부되거나 이력이 꼬입니다. ✅ 개인 브랜치, 아직 공유하지 않은 커밋만 rebase 합니다.

❌ 실수 2: rebase 충돌 후 add 없이 --continue 한다

git 이 아직 해결되지 않았다고 판단해 같은 커밋에서 다시 멈춥니다. ✅ 마커를 정리하고 git add 로 해결을 표시한 뒤 --continue 합니다.

❌ 실수 3: rebase -i 화면에서 fixup 대상 줄을 착각한다

fixup·squash 는 바로 위 줄의 커밋에 합쳐집니다. 순서를 잘못 두면 엉뚱한 커밋에 합쳐집니다. ✅ 합칠 대상 커밋 바로 다음 줄에 fixup·squash 를 둡니다.

❌ 실수 4: cherry-pick 범위에서 시작 커밋을 빠뜨린다

A..B 는 A 를 포함하지 않아 첫 커밋이 안 옮겨집니다. ✅ A 도 포함하려면 A^..B 로 씁니다.

❌ 실수 5: cherry-pick 충돌을 병합 충돌과 다르게 생각한다

해결 순서는 rebase 와 같습니다. ✅ 마커 정리 → git add → git cherry-pick --continue 입니다.

❌ 실수 6: --force 로 습관적으로 push 한다

동료가 그 사이 push 한 커밋을 통째로 지울 수 있습니다. ✅ 항상 --force-with-lease 를 쓰고, 거부되면 fetch 후 다시 확인합니다.

❌ 실수 7: merge --squash 뒤 원본 브랜치를 정리하지 않는다

merge --squash 는 병합 관계를 남기지 않으므로 원본 브랜치는 git 이력상 합쳐진 것으로 표시되지 않습니다. ✅ 스쿼시 병합 후에는 원본 브랜치를 삭제해 착각을 막습니다.

❌ 실수 8: rebase -i 에서 drop 한 커밋이 완전히 사라졌다고 생각한다

drop 한 커밋도 당장은 저장소 안에 남아 있습니다. ✅ git reflog 로 rebase 직전 위치를 찾아 되돌릴 수 있습니다.

❌ 실수 9: pull --rebase 중 충돌이 나면 당황해 무작정 --abort 한다

--abort 는 pull 시도만 취소할 뿐 이전 작업이 사라지지는 않습니다. ✅ 충돌을 해결하고 --continue 하거나, 급하면 --abort 후 다시 시도합니다.

❌ 실수 10: rebase -i 범위를 너무 크게 잡는다

HEAD~N 을 크게 잡으면 이미 팀이 받아간 커밋까지 대상에 섞입니다. ✅ git log --oneline 으로 정리할 범위를 먼저 확인하고 N 을 정합니다.