Cherry-pick — 정의, 메커니즘 및 Git에서의 적용

Cherry-pick이란?

Cherry-pick은 지정된 커밋에서 변경 사항을 복사하여 현재 브랜치에 새 커밋으로 적용하는 Git 명령어입니다. 이름은 “체리 고르기”의 은유에서 유래했습니다. 개발자는 필요한 커밋만 선택하고 나머지는 무시합니다.

Merge와 달리 cherry-pick은 병합 커밋을 생성하지 않으며 브랜치의 전체 병합이 필요하지 않습니다. Rebase와 달리 cherry-pick은 커밋 시퀀스를 전송하지 않고 지정된 것만 전송합니다. 이로 인해 cherry-pick은 수정 사항을 선택적으로 전송하는 데 이상적인 도구입니다.

Atlassian, 2025에 따르면 cherry-pick은 여러 릴리스 브랜치를 동시에 작업하는 팀의 47%가 사용합니다. Cherry-pick은 특히 모바일 개발에서 수요가 많으며, 애플리케이션의 여러 버전(LTS 릴리스)이 동시에 유지 관리되고 그들 사이에 수정 사항을 전송해야 합니다.

전송 메커니즘

Cherry-pick을 실행하면 Git은 지정된 커밋과 그 부모 간의 diff를 계산한 다음 이 diff를 현재 브랜치에 적용합니다. 변경 사항이 충돌 없이 적용되면 Git은 동일한 메시지지만 새 SHA로 새 커밋을 생성합니다. 충돌이 있으면 cherry-pick이 수동 해결을 위해 일시 중지됩니다.

Cherry-pick 작동 방식

구문은 간단합니다. 전송할 커밋의 해시를 지정합니다. Git은 변경 사항을 현재 브랜치에 새 커밋으로 복사합니다. 한 번에 여러 커밋과 전체 범위의 전송이 지원됩니다.

# 현재 브랜치에 단일 커밋 전송
git cherry-pick a1b2c3d4

# 여러 커밋 전송
git cherry-pick a1b2c3d4 e5f6g7h8

# 커밋 범위 전송(a1b2에서 f9e8까지, a1b2 제외)
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick 실행 후 현재 브랜치는 소스의 변경 사항이 포함된 새 커밋을 받습니다. 커밋 메시지는 기본적으로 소스에서 복사되지만 -n 플래그(커밋하지 않음) 또는 --edit(메시지 편집)으로 수정할 수 있습니다.

수정 사항 전송 예시

일반적인 시나리오를 생각해 봅시다. develop에서 중요한 버그를 찾아 수정했으며, 이 버그는 릴리스 브랜치 release/v2.0에도 존재합니다. develop 전체를 릴리스 브랜치에 병합하지 않고 이 수정 사항만 전송해야 합니다.

# develop에서 수정 사항이 있는 커밋 해시 찾기
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# 릴리스 브랜치로 전환
git checkout release/v2.0

# 수정 사항 적용
git cherry-pick a1b2c3d4

# 충돌이 있으면 — 해결하고 계속
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x 플래그는 커밋 메시지에 원본 SHA에 대한 참조를 추가합니다: “(cherry picked from commit a1b2c3d4)”. 이렇게 하면 커밋이 어디서 전송되었는지 추적하기 쉽습니다. 임시 초안을 제외한 모든 시나리오에서 -x를 사용하는 것이 좋습니다.

충돌 작업

충돌이 발생하면 cherry-pick은 merge처럼 동작합니다. Git이 중지되고 충돌 파일을 표시합니다. 개발자가 충돌을 해결하고 git add를 실행한 다음 git cherry-pick --continue를 실행합니다. 취소하려면 — git cherry-pick --abort. --strategy 플래그는 병합 전략(예: 옵션이 있는 recursive)을 지정할 수 있습니다.

# Cherry-pick 중 충돌 해결
# Git이 충돌 파일 표시
git status

# 수동으로 해결, 그런 다음:
git add 허용된_파일.kt
git cherry-pick --continue

# 또는 cherry-pick 중단:
git cherry-pick --abort

Cherry-pick 사용 시기

Cherry-pick은 전체 브랜치를 병합하지 않고 변경 사항을 선택적으로 전송해야 하는 시나리오에 최적입니다. Cherry-pick이 최선의 선택이 되는 다섯 가지 주요 경우를 살펴보겠습니다.

• Hotfix 전송 — develop에서 수정 사항을 찾았지만 릴리스 브랜치(release/v2.0)에 적용해야 합니다. Cherry-pick은 develop의 미완성 기능에 영향을 주지 않고 수정 커밋만 전송합니다
• 이전 버전으로 백포트 — 현재 버전의 수정 사항을 LTS 릴리스로 전송해야 합니다. 전체 코드베이스를 병합하는 대신 cherry-pick이 필요한 커밋만 선택합니다
• 잘못된 브랜치의 커밋 실행 취소 — 커밋이 잘못된 브랜치에서 이루어진 경우 cherry-pick이 올바른 브랜치로 전송하고 원래 커밋은 되돌려집니다
• 문서 전송 — 모든 브랜치에 있어야 하는 README 또는 구성 파일의 변경 사항은 cherry-pick을 통해 전송하기 편리합니다
• 선택적 적용 — 프로토타입 브랜치에서 전체 프로토타입을 주요 개발에 전송하지 않고 성공한 하나의 커밋만 가져와야 합니다

모바일 개발에서 cherry-pick은 애플리케이션의 여러 버전을 지원할 때 중요합니다. 예를 들어 이미 Google Play에 출시된 버전 3.2에서 버그가 발견되고 develop에 버전 4.0의 코드가 있는 경우 cherry-pick을 사용하면 모든 호환되지 않는 변경 사항을 병합하지 않고 v3.x 브랜치로 수정 사항을 전송할 수 있습니다. 이는 서로 다른 API와 종속성을 가진 두 개 이상의 주요 버전을 동시에 유지 관리하는 프로젝트에서 특히 중요합니다.

실제 예시: 모바일 앱에서 Android 12의 Google Sign-In 인증 중 충돌이 감지되었습니다. 수정 사항은 develop에서 이루어지고 코드 리뷰를 통과합니다. 그러나 현재 릴리스 브랜치 v2.5는 이미 베타 테스트 단계에 있습니다. Develop에서 release/v2.5로 수정 커밋을 Cherry-pick하면 아직 릴리스 준비가 되지 않은 다른 변경 사항을 전송하지 않고 다음 릴리스에 수정 사항을 포함할 수 있습니다.

모바일 프로젝트에서 cherry-pick을 사용할 때는 종속성을 고려하는 것이 중요합니다. 수정 사항이 릴리스 브랜치의 분기점 이후 develop에서 변경된 파일에 영향을 미치는 경우 cherry-pick이 불완전한 변경 세트를 가져올 수 있습니다. 이러한 경우 모든 관련 변경 사항도 전송되었는지 확인해야 합니다. 그렇지 않으면 애플리케이션이 빌드되지 않거나 올바르게 작동하지 않을 수 있습니다. 공유 브랜치로 변경 사항을 푸시하기 전에 항상 cherry-pick 후 빌드를 확인하세요.

Cherry-pick vs Merge vs Rebase

Git에서 변경 사항을 통합하는 세 가지 주요 도구 — merge, rebase 및 cherry-pick — 은 서로 다른 작업을 해결합니다. 선택은 전송해야 하는 변경 사항의 양과 기록이 어떻게 보여야 하는지에 따라 달라집니다.

Merge — 두 브랜치를 완전히 병합하고 분기 정보를 유지해야 하는 경우. Rebase — 깔끔한 기록으로 개인 브랜치를 최신 상태로 업데이트해야 하는 경우. Cherry-pick — 하나의 커밋 또는 여러 선택된 커밋만 필요한 경우.

실제로 이러한 도구는 결합됩니다. 기능은 develop에 정기적인 rebase로 개발된 다음 --no-ff merge를 통해 병합되고, 다른 브랜치로 수정 사항을 전송해야 할 때 cherry-pick이 사용됩니다. 각 도구는 각 단계에서 각자의 작업을 해결합니다.

Cherry-pick의 위험 및 제한 사항

Cherry-pick은 유용하지만 잘못 사용하거나 과도하게 사용하면 잠재적으로 위험한 도구입니다. 주요 위험은 커밋 중복, 컨텍스트 손실 및 이후 병합 시 충돌과 관련됩니다.

• 커밋 중복 — 동일한 커밋이 나중에 merge를 통해 브랜치에 들어오면 Git이 변경 사항에서 동일한 두 번째 커밋을 생성합니다. 이는 기록을 오염시키고 git bisect를 어렵게 만듭니다
• 컨텍스트 손실 — cherry-pick은 diff를 전송하지만 부모 커밋 및 종속성에 대한 정보는 전송하지 않습니다. Cherry-pick이 A가 의존했던 커밋 B 없이 커밋 A를 적용한 경우 논리적 오류가 발생할 수 있습니다
• 병합 충돌 — cherry-pick 후 전체 브랜치 병합 중에 Git이 동일한 변경 사항을 두 번 보고 일반 병합에서 피할 수 있었던 충돌을 생성할 수 있습니다
• 추적 가능성 부족 -x 플래그 없이는 커밋이 다른 브랜치에서 전송되었는지 알 수 없습니다. 변경 사항의 출처를 찾을 때 개발자는 커밋의 출처를 파악하는 데 몇 시간을 소비할 수 있습니다

위험 최소화를 위한 권장 사항: 원본 SHA를 표시하기 위해 항상 -x 플래그를 사용하고, 커밋 메시지에 cherry-pick 이유를 문서화하며, 가능한 경우 컨텍스트가 허용할 때 cherry-pick 대신 merge를 사용하십시오. Cherry-pick이 많아지면 브랜치 재구성을 고려하십시오.

Cherry-pick 자동 검사

CI 파이프라인은 cherry-pick을 별도의 시나리오로 고려해야 합니다. 자동 검사를 설정하는 것이 좋습니다. cherry-pick 커밋이 생성되면 CI는 변경된 파일이 예상 세트와 일치하는지 확인하고 영향을 받는 모듈에 대한 테스트를 실행합니다. 이는 브랜치 간 변경 사항을 전송할 때 회귀 위험을 줄여줍니다.