Git rebase 충돌 해결 방법 5단계
목차
깃 rebase 중 충돌이 나면 먼저 git status로 충돌 파일을 확인하고, 파일 내용을 직접 정리한 뒤 git add와 git rebase --continue를 실행하면 됩니다. 충돌이 여러 커밋에서 차례로 생길 수 있으므로, rebase가 끝났다는 안내가 나올 때까지 같은 과정을 반복하세요.
rebase 충돌은 왜 발생할까?
커밋을 새 기준 위에 다시 적용하기 때문입니다
rebase(기준 커밋을 바꿔 기존 커밋을 다시 적용하는 작업)는 현재 브랜치의 커밋들을 대상 브랜치의 최신 커밋 위에 하나씩 다시 적용합니다. 이때 두 쪽의 변경을 Git이 자동으로 합칠 수 없으면 충돌이 발생해 작업이 멈춥니다. 충돌은 같은 줄을 수정한 경우뿐 아니라 서로 영향을 주는 파일 변경에서도 생길 수 있습니다.
충돌 해결은 커밋마다 반복될 수 있습니다
작업 브랜치에 커밋이 여러 개 있으면 Git은 순서대로 각 커밋을 적용합니다. 앞 커밋의 충돌을 해결해 계속 진행한 뒤, 다음 커밋에서 다시 멈출 수 있습니다. 첫 번째 충돌을 해결했다고 해서 전체 rebase가 끝난 것은 아닙니다. 멈출 때마다 상태와 해당 변경의 의도를 확인하세요.
rebase 도중 충돌이 나면 파일을 수정해 스테이징한 뒤
git rebase --continue로 진행합니다. 일반적으로 충돌 해결만을 위해 별도 커밋을 만들 필요는 없습니다.
rebase 충돌 해결 방법: 순서대로 진행하기
아래 예시에서는 작업 브랜치를 feature/login, 기준 브랜치를 main이라고 가정합니다. 실제 저장소의 브랜치 이름으로 바꾸세요. 원격 기준 브랜치를 사용하려면 fetch로 원격 정보를 가져온 뒤 진행합니다. rebase를 시작하기 전에 작업 중인 변경사항을 커밋하거나 임시 보관하고, 현재 브랜치가 맞는지 확인하세요.
1단계: 현재 브랜치와 rebase 상태 확인
rebase 대상은 작업 브랜치입니다. 다른 브랜치에서 시작했거나 브랜치 이름이 헷갈린다면 먼저 현재 위치를 확인하세요. rebase가 충돌로 멈춘 상태라면 git status가 해결할 파일과 진행 상황을 보여줍니다.
git switch feature/login
git fetch origin
git rebase origin/main
git status로컬의 main을 기준으로 할 때는 origin/main 대신 main을 사용할 수 있습니다. git fetch는 원격 정보를 가져오는 명령입니다. 원격 정보를 가져오지 않은 채 오래된 기준으로 rebase하면 최신 변경이 빠질 수 있습니다.
2단계: 충돌 표시를 읽고 의도대로 수정
충돌 파일에는 다음과 같은 구분 표시가 있을 수 있습니다. rebase 중에는 <<<<<<< HEAD와 ======= 사이에 rebase 기준 쪽 내용이, =======와 >>>>>>> 사이에 다시 적용 중인 커밋의 내용이 표시됩니다. 이 구분 표시는 해결 뒤 파일에서 제거해야 합니다.
<<<<<<< HEAD
기준 브랜치의 변경
=======
다시 적용 중인 커밋의 변경
>>>>>>> 커밋 식별자둘 중 하나를 무조건 고르기보다 각 변경의 목적을 확인하고 필요한 내용을 합쳐 최종 파일을 만드세요. rebase 중에는 ours와 theirs가 가리키는 쪽이 평소 예상과 다를 수 있습니다. 표시 이름만 보고 한쪽을 일괄 선택하지 말고, 파일을 저장한 뒤 충돌 표시가 남아 있지 않은지 확인하세요.
3단계: 해결한 파일을 스테이징하고 rebase 계속하기
수정을 마친 파일을 Git에 충돌 해결 완료 상태로 알립니다. 여러 파일을 수정했다면 모두 추가하고, 상태를 다시 확인한 다음 계속 진행합니다.
git add src/login.ts
git status
git rebase --continue편집기가 커밋 메시지를 보여주면 내용을 확인하고 저장한 뒤 닫습니다. 이후 다음 커밋에서 충돌이 생기면 2단계와 3단계를 반복하세요.
4단계: 완료 여부와 변경 내용 검토
rebase가 완료되면 git status로 작업 트리가 예상한 상태인지 확인하고, 최근 커밋 흐름과 변경사항을 살펴봅니다. 충돌 해결 과정에서 상대 브랜치의 수정이나 내 기능 일부를 빠뜨리지 않았는지 검토하세요.
git status
git log --oneline --graph -10
git diff origin/main...HEAD마지막 명령은 기준 브랜치와 현재 브랜치 사이의 변경을 확인하는 예입니다. 프로젝트에 맞는 검토 절차가 있다면 그 절차도 따르세요. 충돌 해결은 표시를 없애는 데 그치지 않고 양쪽 작업의 의도를 보존했는지 확인하는 과정입니다.
5단계: 원격 브랜치에 반영하기
rebase는 커밋을 다시 만들어 해시(커밋을 식별하는 값)가 달라질 수 있습니다. 해당 브랜치를 이미 원격에 올렸다면 일반 push가 거부될 수 있습니다. 강제 푸시가 필요한 개인 작업 브랜치라면 먼저 팀 규칙을 확인하고, 원격 브랜치의 변경사항을 살펴 필요한 커밋을 반영하세요.
git push --force-with-lease origin feature/login--force-with-lease는 로컬의 원격 추적 참조가 기억하는 원격 상태가 실제 원격 브랜치와 다르면 푸시를 거부하는 보호 장치입니다. 이 명령만으로 모든 변경을 안전하게 확인해 주는 것은 아닙니다. 특히 푸시 직전에 git fetch로 원격 추적 참조를 갱신하면, 아직 내 작업에 반영하지 않은 원격 커밋이 lease의 기준에 포함될 수 있습니다. fetch 후 새 커밋이 보이면 먼저 내용을 확인하고 작업에 반영한 뒤 푸시하세요. 백그라운드 fetch가 참조를 갱신할 수도 있으므로 공유 브랜치의 이력을 바꾸기 전에는 팀과 조율해야 합니다. --force는 원격 커밋을 잃게 할 수 있으므로 습관적으로 사용하지 마세요.
continue·abort·skip 중 무엇을 선택할까?
명령 | 동작 | 선택할 때 |
|---|---|---|
| 충돌 해결을 확인하고 다음 커밋 적용 | 변경을 살려 진행할 때 |
| rebase를 중단하고 시작 전 상태로 복귀 | 판단이 어렵거나 처음부터 다시 할 때 |
| 현재 적용 중인 커밋을 건너뜀 | 그 커밋의 변경이 불필요함을 확인했을 때 |
--skip은 충돌 파일 일부만 무시하는 명령이 아닙니다. 현재 적용 중인 커밋 자체를 건너뛰므로 그 커밋에서 필요한 수정도 함께 빠질 수 있습니다. 변경사항을 보존할지 확신할 수 없다면 skip을 선택하기 전에 해당 커밋을 확인하거나 rebase를 중단하세요.
공유 중인 브랜치의 커밋을 이미 push했다면, rebase로 이력을 바꾸기 전에 팀과 조율하세요. 다른 사람이 기존 커밋을 기반으로 작업했을 수 있습니다.
자주 생기는 실수와 복구 요령
충돌 표시만 지우고 스테이징하지 않음: 수정 후 해당 파일을
git add해야 Git이 해결 완료로 인식합니다.충돌이 하나뿐이라고 생각함: 커밋을 하나씩 적용하므로 다음 단계에서 다른 충돌이 생길 수 있습니다.
skip을 빠른 해결로 사용함: 커밋의 변경 전체가 빠질 수 있으니 변경 목적을 확인하세요.
공유 브랜치를 강제 푸시함: 원격의 다른 작업을 덮어쓸 위험이 있습니다. 원격 상태와 팀 규칙을 확인하고 조율하세요.
merge와 rebase 진행 명령을 혼동함: rebase 충돌은 보통 해결 후
git rebase --continue로 진행합니다.
진행을 취소하려면 git rebase --abort를 실행하면 됩니다. 저장소 상태가 예상과 다르거나 충돌을 어떻게 합칠지 판단하기 어렵다면, 무리하게 계속하지 말고 abort한 뒤 최신 상태와 작업 내용을 다시 확인하세요.
자주 묻는 질문
Q. 충돌 파일을 고친 뒤 git commit을 해야 하나요?
아니요. 수정한 파일을 git add로 스테이징한 뒤 git rebase --continue를 실행하세요. rebase가 적용 중인 커밋을 이어서 처리합니다.
Q. rebase 중 충돌이 여러 번 나도 정상인가요?
네. 작업 브랜치의 커밋을 하나씩 다시 적용하므로 여러 커밋에서 각각 충돌할 수 있습니다. 매번 상태와 변경 내용을 확인하고 해결한 뒤 계속 진행하면 됩니다.
Q. git rebase --skip은 언제 써야 하나요?
현재 적용 중인 커밋의 변경사항을 통째로 제외해도 된다고 확인했을 때만 사용하세요. 충돌을 해결하는 일반적인 대체 명령이 아니며 필요한 작업을 누락할 수 있습니다.
Q. rebase가 끝난 뒤 push가 거부되면 어떻게 하나요?
원격 브랜치에 새 커밋이 있는지 확인하고, 있다면 내용을 검토해 작업에 반영하세요. 강제 푸시가 팀 규칙상 허용되는 개인 브랜치라면 git push --force-with-lease를 사용할 수 있습니다. 공유 브랜치라면 이력을 덮어쓰기 전에 팀과 조율해야 합니다.
