숏컷 코드

git switch release/1.0
git cherry-pick a1b2c3d

# 여러 커밋을 순서대로 적용
git cherry-pick a1b2c3d e4f5g6h

# 범위 지정 (이전 커밋 제외, 이후 커밋 포함)
git cherry-pick a1b2c3d..e4f5g6h

문법

어떤 커밋 이동 방식을 먼저 떠올리면 되나

cherry-pick은 "변경 내용"을 새 커밋으로 재현하는 것이지 커밋 자체를 이동하는 것이 아니다

cherry-pick을 실행하면 Git은 대상 커밋이 부모 커밋에서 만든 diff를 계산한 뒤, 그 diff를 현재 브랜치에 새 커밋으로 적용합니다. 결과적으로 원본과 내용은 같지만 SHA가 다른 새 커밋이 생깁니다. 이 점이 merge와 근본적으로 다릅니다. merge는 두 히스토리의 공통 조상을 기준으로 통합하지만, cherry-pick은 선택한 커밋의 변화량만 재적용합니다.

# main 브랜치의 버그 수정 커밋을 release에도 적용
git switch release/2.1
git cherry-pick f7a3e91   # main 브랜치의 "Fix null pointer in auth" 커밋
# → release/2.1에 새로운 SHA를 가진 동일 변경 커밋이 생성됨

의존 커밋을 빠뜨리면 충돌이 아니라 조용한 오동작이 생길 수 있다

cherry-pick의 가장 위험한 함정은 충돌이 나지 않아도 틀릴 수 있다는 점입니다. 예를 들어 커밋 B가 커밋 A에서 추가한 함수를 호출하는 구조라면, A 없이 B만 cherry-pick해도 텍스트 충돌은 없지만 런타임에 오동작합니다. cherry-pick 전에 반드시 대상 커밋이 의존하는 선행 변경이 목표 브랜치에 이미 있는지 확인해야 합니다.

# 의존 관계 확인: 커밋 상세 보기
git show a1b2c3d

# 목표 브랜치에 의존 함수가 있는지 확인
git switch release/1.0
git log --oneline | grep "Add helper function"

hotfix backport가 cherry-pick의 가장 자연스러운 사용처다

main에 병합된 버그 수정을 이미 릴리스된 브랜치에도 반영해야 할 때, 브랜치 전체를 merge하면 준비되지 않은 기능까지 딸려 옵니다. cherry-pick은 수정 커밋 하나만 정확히 골라 낼 수 있어 backport에 이상적입니다. 다만 같은 변경이 여러 브랜치에 별도 커밋으로 존재하게 되므로, 나중에 git log 추적 시 혼란이 생길 수 있다는 트레이드오프가 있습니다.

# main에서 버그 수정 커밋 SHA 확인
git log main --oneline --grep="Fix"

# release 브랜치에 backport
git switch release/1.0
git cherry-pick 9f2c1a4
git push

cherry-pick과 merge는 "가져오는 범위"가 다르다

fix 한두 개만 릴리스 브랜치에 가져오려면 cherry-pick이 맞고, 기능 브랜치 전체 맥락을 유지한 채 통합하려면 merge가 맞습니다. cherry-pick은 필요한 커밋만 정확히 골라서 가져오는 대신, 의존 커밋을 빠뜨리면 조용히 깨질 수 있습니다. merge는 범위가 넓지만 브랜치 전체 히스토리 맥락을 유지합니다.

# 특정 hotfix만 backport
git cherry-pick 9f2c1a4

# 기능 브랜치 전체 반영
git merge feature/login

선택 기준

주의할 점

# helper 추가 commit은 제외하고
# helper를 사용하는 commit만 가져오면
git cherry-pick b2c3d4e

# 텍스트 충돌이 없어도 build/test 단계에서 깨질 수 있음