정의
git cherry-pick은 “특정 커밋의 변경사항만 현재 브랜치 위로 복사”하는 명령
git cherry-pick은 지정한 커밋(들)이 만들어낸 변경사항을 현재 브랜치에 적용하고, 각 커밋마다 “새 커밋”을 하나씩 생성합니다. 따라서 같은 변경이라도 커밋 SHA는 새로 생성됩니다(히스토리 복제가 아니라 “패치 재적용”에 가깝습니다).
중요 조건: cherry-pick은 보통 “작업 트리가 깨끗(clean)”해야 시작할 수 있다
실무 감각: “브랜치 전체를 합치고 싶지 않은데, 특정 커밋 하나만 필요할 때” 가장 깔끔합니다.
핵심 메시지
cherry-pick은 “merge의 대체재”가 아니라 “선택적 이식 도구”입니다. 잘 쓰면 백포트/핫픽스가 편하지만, 남용하면 중복 커밋과 히스토리 혼선을 만들 수 있습니다.
동작 원리
“커밋을 가져오는 것”이 아니라 “그 커밋의 변경을 다시 적용”한다
cherry-pick은 내부적으로 “해당 커밋이 만든 diff(패치)”를 현재 HEAD 위에 적용하고, 새 커밋을 만듭니다. 그래서 동일 변경이라도 커밋 ID가 동일하지 않습니다.
충돌(conflict)이 나면?
충돌이 나면 Git은 진행을 멈추고, 어떤 커밋을 처리하다 막혔는지 CHERRY_PICK_HEAD를 세팅해둡니다. 인덱스에는 충돌 파일의 여러 버전(stage)이 기록되고, 워킹트리 파일에는 <<<<<<< 같은 충돌 마커가 들어갑니다.
언제 쓰나
가장 흔한 3가지 시나리오
1) 백포트(backport)
main의 특정 버그픽스 커밋만 release/maint 브랜치에 이식
2) 잘못된 브랜치에 커밋했을 때
커밋을 “원래 있어야 할 브랜치”로 복사하고, 원 브랜치에서는 정리(revert/reset 등)
3) PR을 아직 머지하기는 이르지만, 특정 커밋만 먼저 필요할 때
큰 브랜치를 통째로 합치지 않고, 필요한 변경만 선별 적용
기본 사용법
단일/다중/범위 cherry-pick + 실전 옵션(-x, -n)
가장 자주 쓰는 커맨드
# 1) 커밋 하나만 적용
git cherry-pick <commit_sha>
# 2) 커밋 여러 개를 “지정한 순서대로” 적용 (나열한 그대로 처리)
git cherry-pick <sha1> <sha2> <sha3>
# 3) 범위로 적용 (예: master에 있고 HEAD에 없는 것들)
git cherry-pick ..master
# 4) -x : 커밋 메시지에 "cherry picked from ..." 흔적 남기기 (백포트에 강추)
git cherry-pick -x <commit_sha>
# 5) -n/--no-commit : 워킹트리/인덱스에만 적용하고 커밋은 내가 직접 한 번에
git cherry-pick -n <commit_sha>
# 6) --edit : 메시지 수정하고 커밋
git cherry-pick -e <commit_sha>-x는 백포트/핫픽스에서 추적성을 크게 올려줍니다. 반대로, 완전히 사적인 브랜치에서만 쓸 거라면 의미가 약할 수 있습니다.
충돌 해결
conflict가 났을 때의 표준 루틴: continue / abort / skip
1) 상태 확인
git status로 충돌 파일 목록을 확인
2) 충돌 해결
충돌 마커 정리 후 git add로 stage
3) 진행/취소
continue로 재개, abort로 원복, 필요하면 skip
# 충돌 난 상태에서
git status
# 충돌 해결 후
git add <conflicted_files>
# cherry-pick 이어서 진행
git cherry-pick --continue
# 이번 cherry-pick 자체를 취소(원래 상태로)
git cherry-pick --abort
# 충돌 난 “이 커밋”은 건너뛰고 다음으로 (상황에 따라 사용)
git cherry-pick --skip
고급 옵션 · 주의사항
merge commit / 중복 커밋 / 히스토리 혼선 포인트
1) merge commit을 cherry-pick 해야 한다면 (-m/--mainline)
merge 커밋은 “부모가 2개 이상”이라 어떤 쪽을 기준(mainline)으로 재생할지 애매합니다. 이때 -m <parent-number>로 기준 부모를 지정해야 합니다.
# merge commit을 가져올 때 mainline(부모 번호)을 지정
git cherry-pick -m 1 <merge_commit_sha>2) cherry-pick 남용의 대표 부작용: “중복 커밋”
cherry-pick은 원래 커밋을 “그대로 옮기는 게 아니라 새 커밋을 만든다” 보니, 같은 변경이 다른 경로(merge, rebase, 다른 cherry-pick)로 들어오면 팀 히스토리에 “비슷한 커밋이 여러 개” 생길 수 있습니다. 그래서 Atlassian도 cherry-pick은 유용하지만 항상 최선은 아니며, 상황에 따라 merge가 더 낫다고 설명합니다.
3) 팁: 백포트에는 -x를 거의 표준으로
“이 변경은 어디서 왔는지”를 남기려면 -x가 가장 가성비 좋습니다. 나중에 audit/debugging 때 큰 도움이 됩니다.
실전 워크플로우
release 브랜치에 “main의 버그픽스 1개만” 백포트하기
# 1) main에서 백포트할 커밋 SHA 확인
git checkout main
git log --oneline
# 2) release 브랜치로 이동
git checkout release/1.2
# 3) 백포트(추적성을 위해 -x 권장)
git cherry-pick -x <fix_commit_sha>
# 4) 충돌 나면 해결 후
# git add ...
# git cherry-pick --continue
# 5) push & PR
요약
체크리스트로 마무리
CHECK
✅ cherry-pick은 커밋을 복사해서 새 커밋을 만든다(SHA가 바뀜)
✅ 보통 작업 트리 clean 상태에서 시작
✅ 충돌 시: add → --continue, 취소는 --abort
✅ 백포트는 -x로 추적성 확보
✅ merge commit cherry-pick은 -m이 필요할 수 있음
✅ 남용하면 중복 커밋/히스토리 혼선 → “선택적 이식” 용도로만
728x90