topic난이도 · 약 25

Git 심화 — 브랜치·머지·리베이스·충돌 해결

merge vs rebase, conflict 해결, cherry-pick, stash — AI와 협업에서 망치지 않는 브랜치 운영.

#Git#merge#rebase#cherry-pick#conflict#reflog
왜 배우는가

Claude Code가 만든 변경을 잘못 merge하거나 conflict에서 당황해서 강제 리셋하면 몇 시간 작업이 날아간다. 이 토픽으로 '되돌릴 수 있다'는 안전감을 확보한다.

ch03-3에서 `init/add/commit/push`까지 배웠다면, 여기선 실무에서 매일 만나는 4가지: 브랜치 전환, merge/rebase 선택, 충돌 해결, 실수 복구.

머지와 리베이스는 두 브랜치를 합치는 두 가지 방식이다. 결과물은 같아 보이지만 히스토리 모양이 다르다.

merge vs rebase — merge는 합류 커밋 남김, rebase는 히스토리 직선화
명령효과히스토리 모양언제?
`git merge feature`두 갈래를 하나로 합치고 merge 커밋 생성갈라졌다가 합쳐지는 Y자main 같은 공유 브랜치
`git rebase main`feature 커밋들을 main 위로 이식일자 직선push 전 내 로컬 브랜치
`git merge --squash feature`feature의 모든 커밋을 한 커밋으로 압축깔끔PR 머지의 표준
bash
# 시나리오: 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이 자동 결정을 포기하고 당신에게 넘긴다. 파일을 열면 이런 마커가 보인다:

text
<<<<<<< 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은 '다른 브랜치의 특정 커밋 하나만' 가져오기. 핫픽스 같은 실전에서 필수.

bash
# 프로덕션 브랜치에 feature 브랜치의 버그픽스 1개만 옮기기
git checkout production
git cherry-pick <커밋해시>

# 여러 커밋 범위
git cherry-pick A..B         # A 이후 ~ B까지

# 충돌 나면 merge와 동일: 수정 → add → git cherry-pick --continue

feature 브랜치 머지는 위험한데 핫픽스 커밋만 급히 프로덕션에 올리고 싶을 때 사용.

bash
# 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 (예방이 최선)
실기 드릴 3문항
check_circle실기 드릴 · OX

이미 push된 브랜치에 rebase를 해도 괜찮다.

edit실기 드릴 · 단답형

다른 브랜치의 특정 커밋 하나만 현재 브랜치에 가져오는 명령은?

edit실기 드릴 · 단답형

`git reset --hard`로 날아간 커밋을 복구할 때 단서를 찾는 명령은?