Git 심화 — 브랜치·머지·리베이스·충돌 해결
merge vs rebase, conflict 해결, cherry-pick, stash — AI와 협업에서 망치지 않는 브랜치 운영.
Claude Code가 만든 변경을 잘못 merge하거나 conflict에서 당황해서 강제 리셋하면 몇 시간 작업이 날아간다. 이 토픽으로 '되돌릴 수 있다'는 안전감을 확보한다.
ch03-3에서 `init/add/commit/push`까지 배웠다면, 여기선 실무에서 매일 만나는 4가지: 브랜치 전환, merge/rebase 선택, 충돌 해결, 실수 복구.
머지와 리베이스는 두 브랜치를 합치는 두 가지 방식이다. 결과물은 같아 보이지만 히스토리 모양이 다르다.
| 명령 | 효과 | 히스토리 모양 | 언제? |
|---|---|---|---|
| `git merge feature` | 두 갈래를 하나로 합치고 merge 커밋 생성 | 갈라졌다가 합쳐지는 Y자 | main 같은 공유 브랜치 |
| `git rebase main` | feature 커밋들을 main 위로 이식 | 일자 직선 | push 전 내 로컬 브랜치만 |
| `git merge --squash feature` | feature의 모든 커밋을 한 커밋으로 압축 | 깔끔 | PR 머지의 표준 |
# 시나리오: feature 브랜치에서 작업 중, main에 새 커밋이 들어옴
# 방법 A) merge — 공유 브랜치 OK, 히스토리 복잡
git checkout feature
git merge main # merge 커밋 생김
# 방법 B) rebase — 히스토리 깔끔, 단 push된 브랜치엔 금지
git checkout feature
git rebase main # feature 커밋들이 main 최신 위로 이식됨
# 충돌 발생 시:
# 1) 파일 수정
# 2) git add <파일>
# 3) git rebase --continue
# 포기: git rebase --abort
# 방법 C) PR 머지 — GitHub에서 "Squash and merge" 버튼 = --squash황금률: push 후에는 rebase 금지. 다른 사람이 내 브랜치 기반으로 작업했다면 히스토리가 꼬인다. rebase는 내 로컬에서만.
충돌(Conflict)은 같은 줄을 두 브랜치가 다르게 고쳤을 때 일어난다. Git이 자동 결정을 포기하고 당신에게 넘긴다. 파일을 열면 이런 마커가 보인다:
<<<<<<< HEAD
const price = 1000; // main 쪽 버전
=======
const price = 1200; // feature 쪽 버전
>>>>>>> feature/pricing
해결 절차:
1) 마커를 지우고 원하는 최종 모습만 남긴다
2) git add <파일>
3) git commit (merge 중이면 자동 메시지)
git rebase --continue (rebase 중이면)
포기하고 싶다:
git merge --abort # merge 중이면
git rebase --abort # rebase 중이면Claude Code에게 "이 충돌 파일 봐줘. 둘 다 의미 있으면 합치고, main 쪽이 최신이면 main을 선택해"라고 맡길 수 있다.
cherry-pick은 '다른 브랜치의 특정 커밋 하나만' 가져오기. 핫픽스 같은 실전에서 필수.
# 프로덕션 브랜치에 feature 브랜치의 버그픽스 1개만 옮기기
git checkout production
git cherry-pick <커밋해시>
# 여러 커밋 범위
git cherry-pick A..B # A 이후 ~ B까지
# 충돌 나면 merge와 동일: 수정 → add → git cherry-pick --continuefeature 브랜치 머지는 위험한데 핫픽스 커밋만 급히 프로덕션에 올리고 싶을 때 사용.
# stash — 진행 중 변경을 임시 서랍에 넣기
git stash # 현재 변경 저장 + 작업 폴더 깨끗
git stash pop # 가장 최근 stash 복원
git stash list # 서랍 목록
# reflog — 모든 HEAD 이동 이력 (강제 리셋도 되돌릴 수 있는 최후 수단)
git reflog
# 42f1a3e HEAD@{0}: reset: moving to HEAD~3
# ...
git reset --hard 42f1a3e # 사라진 커밋 복원`git reflog`는 Git의 블랙박스. `reset --hard` 실수로 커밋을 날려도 90일 이내면 reflog에서 되찾을 수 있다. 긴급할 때 기억해야 할 명령.
Claude Code와 Git 협업 3원칙. ① 큰 작업 전엔 새 브랜치부터 만들기. ② Claude가 커밋을 만들었다면 `git log -p`로 변경 내용을 검토한 뒤 push. ③ 커밋 실수 발견 시 `git reset --soft HEAD~1`로 커밋만 취소(변경은 유지).
| 실수 | 복구법 |
|---|---|
| 커밋 메시지 오타 | `git commit --amend -m "새 메시지"` (push 전만) |
| 잘못된 파일 커밋 | `git reset --soft HEAD~1` → 수정 → 재커밋 |
| 잘못된 브랜치에 커밋 | `git reset --hard HEAD~1` → 올바른 브랜치로 이동 → cherry-pick |
| 하드 리셋으로 커밋 날림 | `git reflog` → `git reset --hard <해시>` |
| force push로 남의 작업 덮음 | 각자 reflog로 복구 후 재push (예방이 최선) |
이미 push된 브랜치에 rebase를 해도 괜찮다.
다른 브랜치의 특정 커밋 하나만 현재 브랜치에 가져오는 명령은?
`git reset --hard`로 날아간 커밋을 복구할 때 단서를 찾는 명령은?