git rebase 충돌(CONFLICT) 해결: continue·abort·skip 완벽 가이드

feature 브랜치를 main에 rebase하다가 갑자기 터미널이 이렇게 멈춰버린 적 있으시죠?

CONFLICT (content): Merge conflict in src/app.js
error: could not apply a1b2c3d... feat: add login
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".

여기서 머릿속에 가장 먼저 떠오르는 질문은 보통 이겁니다. "여기서 commit을 해야 하나? abort 누르면 내 작업이 통째로 날아가는 거 아냐?" 결론부터 말씀드릴게요. git rebase --abort를 누르면 rebase를 시작하기 직전 상태로 100% 그대로 돌아옵니다. 작업은 절대 날아가지 않습니다. 그러니 일단 손가락을 키보드에서 떼고 천천히 읽어보세요.

rebase가 "멈추는" 이유: 멘탈 모델부터 잡기

merge와 rebase의 가장 큰 차이는 충돌을 처리하는 단위입니다.

• merge: 두 브랜치를 한 번에 합치므로 충돌도 한 방에 다 터진다.
• rebase: 내 커밋들을 main 위에 하나씩 다시 얹는다. 그래서 충돌도 커밋 단위로, 한 번에 하나씩만 멈춘다.

즉 rebase가 멈췄다는 건 "지금 N번째 커밋을 얹다가 충돌이 났으니, 이것만 해결해주면 나머지를 계속 얹겠다"는 신호입니다. 무서운 에러가 아니라 일시정지 버튼이라고 생각하세요.

2026년 현재 GitHub·GitLab에서 "Rebase and merge" 정책을 기본으로 채택하는 팀이 늘면서, 주니어 개발자도 이 화면을 훨씬 자주 마주칩니다. VS Code나 Cursor의 머지 에디터, AI 어시스턴트가 마커 해소는 도와주지만, --continue를 언제 누를지는 결국 사람이 판단해야 합니다.

지금 어디서 멈췄나: git status 판독법

당황했을 때 가장 먼저 칠 명령은 단 하나, git status입니다.

$ git status
interactive rebase in progress; onto 9f8e7d6
Last command done (1 command done):
   pick a1b2c3d feat: add login
Next commands to do (2 remaining commands):
   pick b2c3d4e feat: add logout
   pick c3d4e5f refactor: auth util
You are currently rebasing branch 'feature/auth' on '9f8e7d6'.

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
	both modified:   src/app.js

no changes added to commit (git add will track these changes)

각 줄이 무슨 뜻인지 표로 정리했습니다.

핵심은 both modified로 표시된 파일만 손보면 된다는 점입니다.

정석 해결: 충돌 마커 해소 → add → --continue

src/app.js를 열면 이런 마커가 보입니다.

function getUser() {
<<<<<<< HEAD            // ⬆️ 윗쪽 = main(이미 얹힌 쪽)
  return fetchUser({ cache: true });
=======                // 경계선
  return fetchUser({ cache: false, retry: 3 });
>>>>>>> a1b2c3d (feat: add login)  // ⬇️ 아랫쪽 = 지금 얹으려는 내 커밋
}

마커 해석은 단 두 가지만 기억하세요.

• <<<<<<< HEAD ~ ======= : 이미 main에 얹혀 있는 코드
• ======= ~ >>>>>>> a1b2c3d : 지금 얹으려는 내 커밋의 코드

원하는 최종 형태로 직접 합친 뒤, 마커 3종(<<<, ===, >>>)을 전부 지웁니다.

function getUser() {
  return fetchUser({ cache: true, retry: 3 }); // 두 의도를 합친 최종 결과
}

이제 전체 워크플로우를 복붙용으로 정리합니다.

# 1) 어디서 멈췄는지 확인
git status

# 2) both modified 파일을 에디터로 열어 마커(<<<, ===, >>>)를 직접 해소
#    (VS Code/Cursor 머지 에디터로 해도 됨)

# 3) 해결한 파일을 '해결됨'으로 표시 — commit이 아니라 add!
git add src/app.js

# 4) rebase 계속 진행 (다음 커밋을 마저 얹는다)
git rebase --continue

# 5) 다음 커밋에서 또 충돌나면? → 2~4번을 그대로 반복

여기서 git commit을 치면 안 되는 이유

흔한 실수가 충돌 해소 후 습관적으로 git commit을 치는 겁니다.

# ❌ 잘못된 예
git add src/app.js
git commit -m "fix conflict"   # 불필요한 커밋이 끼어들어 히스토리가 더러워진다

# ✅ 올바른 예
git add src/app.js
git rebase --continue          # 원래 커밋에 해결분을 합쳐 깔끔하게 진행

rebase 중에는 git이 "원래 그 커밋을 다시 얹는 중"이므로, --continue가 알아서 해당 커밋을 완성합니다. 직접 commit하면 엉뚱한 커밋이 하나 더 생겨 히스토리가 꼬입니다.

후퇴 옵션: --abort로 100% 원상복구 & --skip의 위험성

--abort: 언제든 안전하게 처음으로

머지가 너무 복잡하거나 "이거 지금 할 게 아닌데" 싶으면 망설이지 말고 abort하세요.

git rebase --abort

이 명령은 rebase 시작 직전 상태(ORIG_HEAD)로 완벽 복원합니다. 이미 --continue를 두세 번 한 뒤여도 상관없습니다. 어느 단계에서 멈췄든 abort 한 방이면 모든 게 그대로 돌아옵니다. 그래서 "작업 날아갈까 봐 무서워서 강제 push" 하는 사고를 칠 이유가 전혀 없습니다.

--skip: 코드가 사라질 수 있는 위험한 명령

git rebase --skip

--skip은 지금 충돌난 커밋의 변경분을 통째로 버리고 다음 커밋으로 넘어갑니다. 즉 그 커밋의 코드가 결과물에서 사라질 수 있습니다. 다음 두 경우에만 쓰세요.

• 해당 커밋의 변경이 이미 main에 똑같이 반영되어 빈 커밋이 된 경우
• 의도적으로 그 커밋을 버리기로 결정한 경우

확신이 없다면 --skip 대신 --abort가 항상 안전합니다.

3-way 비교 표

결론: 반복 충돌은 rerere로, 그리고 절대 금지 목록

긴 rebase에서 같은 충돌을 여러 번 해소하게 될 때가 있습니다. 이때 rerere(reuse recorded resolution)를 켜두면 한 번 해결한 방식을 git이 기억했다가 다음에 자동 적용해줍니다.

git config --global rerere.enabled true

마지막으로 rebase 중 절대 하지 말 것 체크리스트입니다.

• ❌ 충돌 해소 후 git commit 직접 치기 → ✅ git rebase --continue
• ❌ rebase 중간에 새 브랜치 만들거나 다른 작업 시작하기 → 끝내거나 abort 먼저
• ❌ 무지성 git push -f → 동료 커밋을 덮어쓸 수 있음
• ✅ 강제 push가 꼭 필요하면 --force-with-lease 사용

# ❌ 위험: 원격이 바뀌었어도 무조건 덮어씀
git push -f

# ✅ 안전: 내가 본 이후 원격이 바뀌었으면 거부됨
git push --force-with-lease

실무 경험 한마디: 저도 주니어 때 충돌 화면이 무서워서 abort 대신 강제 push를 눌렀다가 팀원 커밋을 날린 적이 있습니다. 그 뒤로 원칙을 하나 세웠어요. "확신이 안 서면 무조건 --abort." abort는 비용이 0이고, rebase는 몇 번이고 다시 시도할 수 있습니다. 두려움 때문에 위험한 명령으로 도망치지 마세요.

자주 묻는 질문 (FAQ)

Q. git rebase --abort 하면 지금까지 작업한 코드가 다 사라지나요? A. 아니요. abort는 rebase를 시작하기 직전 커밋 상태로 정확히 되돌릴 뿐, 브랜치에 이미 커밋된 작업은 그대로 보존됩니다. 안심하고 눌러도 됩니다.

Q. 충돌을 해소했는데 You have unmerged paths가 계속 떠요. A. 파일을 수정만 하고 git add로 "해결됨" 표시를 안 했을 가능성이 큽니다. git add <파일> 후 다시 git status로 unmerged paths가 사라졌는지 확인하고 git rebase --continue를 실행하세요.

Q. git rebase --continue와 git rebase --skip 중 헷갈리면 뭘 눌러야 하나요? A. 변경분을 살려야 하면 충돌을 해소하고 --continue, 그 커밋을 버려도 되면 --skip입니다. 확신이 없으면 둘 다 누르지 말고 --abort로 처음으로 돌아가 천천히 다시 시작하세요.