Cherry-pick: 개념, 실행 방법 및 Git 명령어

Git의 cherry-pick이란

Cherry-pick은 기존 커밋의 변경 사항을 가져와 현재 브랜치에 새 커밋으로 적용하는 git cherry-pick 명령어입니다. 원본 커밋은 자체 브랜치에 그대로 남아 있고, 대상 브랜치에 변경 사항의 복사본이 생성됩니다. 이 명령어는 전체 브랜치를 이동하지 않고 특정 수정 사항을 전송해야 할 때 유용합니다.

구문: git cherry-pick <commit-hash>. Git은 지정된 커밋과 그 부모 간의 차이(diff)를 분석하여 현재 브랜치에 적용합니다. 여러 파일이 변경된 경우 모두 함께 전송됩니다. 범위도 허용됩니다: git cherry-pick A..B — A부터 B까지의 모든 커밋(A 제외).

플래그로 기능 확장: -n(--no-commit)은 커밋을 만들지 않고 작업 디렉토리와 인덱스에 변경 사항을 적용합니다 — 여러 커밋의 변경 사항을 하나로 결합해야 할 때 유용합니다. -x 플래그는 커밋 메시지에 (cherry picked from commit ...) 행을 추가하여 기록에서 변경 사항의 출처를 추적하기 쉽게 만듭니다.

# 해시로 단일 커밋 체리픽
git cherry-pick a1b2c3d

# 여러 커밋 체리픽(순차적)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# 자동 커밋 없이 체리픽
git cherry-pick -n a1b2c3d

# -x 플래그가 원본 커밋 참조 추가
git cherry-pick -x a1b2c3d

Cherry-pick 사용 시기

주요 시나리오는 릴리스 브랜치 간 수정 사항 전송입니다. 상상해보세요: develop에서 심각한 버그를 발견하고 수정했습니다. 릴리스 브랜치 release/v2.1은 이미 분리되어 있으며 이 버그도 포함하고 있습니다. develop 전체를 release에 병합하면 많은 미완성 코드가 들어오지만, 단일 수정 커밋에 cherry-pick을 적용하는 것은 안전하고 정확한 해결책입니다.

두 번째 시나리오는 변경 사항을 되돌렸다가 나중에 복원하는 경우입니다. 커밋이 git revert로 되돌려졌고 나중에 그 되돌리기가 실수였음이 밝혀진 경우 — 되돌려진 커밋에 cherry-pick을 적용하면 변경 사항이 복원됩니다. 이것은 되돌리기를 다시 되돌리는 것보다 더 정확하며 반복적인 충돌이 발생하지 않습니다.

세 번째 시나리오는 통합 테스트를 위해 여러 피처 브랜치의 커밋 결합입니다. 여러 미완성 브랜치(미완료 코드 포함)를 병합하는 대신 각 브랜치에서 준비된 커밋만 선택하여 함께 작동하는 방식을 테스트할 수 있습니다.

• 버그 수정 — 미완성 코드 없이 develop에서 release로 수정 사항 전송.
• Hotfix — hotfix 브랜치에서 main과 develop에 동시에 수정 사항 적용.
• 잘못된 되돌리기 취소 — 되돌려진 커밋에 cherry-pick을 적용하여 변경 사항 복원.
• 테스트 — 통합 테스트를 위해 여러 브랜치에서 선택된 커밋 수집.

Cherry-pick vs rebase 및 merge

Cherry-pick은 전체 브랜치가 아닌 개별 커밋 수준에서 작동한다는 점에서 rebase 및 merge와 다릅니다. rebase는 브랜치의 모든 커밋을 전송하고 merge는 두 브랜치를 결합하는 반면, cherry-pick은 필요한 커밋만 선택합니다.그래서 그것은 더 정확한 도구이지만 더 많은 수동 작업이 필요합니다.

또 다른 차이점은 저작자입니다. Cherry-pick 중에 Git은 기본적으로 원본 커밋의 작성자를 유지하지만 committer는 현재 사용자가 됩니다. 커밋 메시지는 -x 플래그를 통해 출처를 추적할 수 있습니다. Rebase 중에는 작성자와 committer 모두 새 해시와 함께 현재 사용자가 됩니다.

성능: 단일 커밋에 cherry-pick을 적용하는 것이 많은 커밋이 있는 두 브랜치를 병합하는 것보다 빠릅니다. 그러나 수십 개의 커밋을 전송해야 하는 경우 임시 브랜치를 만들고 rebase를 수행하는 것이 더 효율적이며 수십 개의 해시를 지정할 필요가 없습니다.

여러 커밋 전송

여러 커밋은 해시를 공백으로 구분하여 하나의 명령어로 전송할 수 있습니다: git cherry-pick A B C. Git은 지정된 순서대로 커밋을 순차적으로 적용합니다. 커밋이 충돌을 일으키면 cherry-pick이 일시 중지되고 개발자가 충돌을 해결한 후 git cherry-pick --continue로 계속 진행해야 합니다.

커밋 범위: git cherry-pick A..B(A 이후 B까지의 모든 커밋, A 제외) 및 git cherry-pick A^..B(A부터 B까지의 모든 커밋 포함). 범위는 부모 관계 없이 브랜치의 모든 커밋을 전송해야 할 때 편리합니다 — 예를 들어, 이전 브랜치에서 새 브랜치로 완성된 기능을 이동할 때 유용합니다.

--strategy 플래그는 Git이 변경 사항을 적용하는 방식을 결정합니다. 기본적으로 recursive 전략이 사용되지만 충돌 측을 자동으로 선택하기 위해 ours 또는 theirs를 지정할 수 있습니다. --mainline 플래그는 병합 커밋에 cherry-pick을 적용할 때 사용되며, diff가 계산되는 부모 번호(1 또는 2)를 지정합니다.

# Cherry-pick 커밋 범위
git cherry-pick develop~5..develop~2

# 병합 커밋 체리픽(부모 지정)
git cherry-pick -m 1 m9n0o1p

# theirs 전략 사용
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# 충돌 해결 후 계속
git cherry-pick --continue

Cherry-pick 시 충돌

Cherry-pick 시 충돌은 전송되는 커밋의 변경 사항이 대상 브랜치에서 변경된 동일한 행에 영향을 미칠 때 발생합니다. Git은 실행을 일시 중지하고 충돌하는 파일을 표시하며 해결을 기다립니다. 상태에서 이러한 파일은 both modified로 표시됩니다.

충돌 해결 단계: 충돌하는 파일을 열고 충돌 표시자(<<<<<<<, =======, >>>>>>>)를 찾아 내용을 편집하고 표시자를 제거한 후 해결된 파일에 git add를 실행하고 git cherry-pick --continue를 실행합니다. 충돌을 해결할 수 없는 경우 — git cherry-pick --abort는 전체 cherry-pick을 취소하고 브랜치를 원래 상태로 되돌립니다.

일반적인 문제: 커밋에 이미 기존 변경 사항과 동등한 변경 사항이 포함되어 있습니다. 이 경우 Git은 cherry-pick 시도 시 “nothing to commit” 또는 “empty commit”을 보고합니다. --keep-redundant-commits 및 --empty=keep 플래그는 시퀀스를 유지하기 위해 Git이 빈 커밋을 만들도록 강제하고, --skip은 이러한 커밋을 건너뛸 수 있습니다.

# Cherry-pick 중 충돌 — 중지
git cherry-pick a1b2c3d
# error: a1b2c3d... 커밋 메시지를 적용할 수 없음

# 충돌 해결 → 인덱스에 추가
git add src/conflicted_file.swift
git cherry-pick --continue

# 빈 커밋 건너뛰기(이미 적용됨)
git cherry-pick --skip

# 전체 중단
git cherry-pick --abort

Cherry-pick 모범 사례

첫 번째 규칙: 전송되는 커밋이 자체적으로 완결된 것인지 항상 확인하세요. 커밋 A가 전송되지 않는 커밋 B의 변경 사항에 의존하는 경우 A에 cherry-pick을 적용하면 빌드가 손상될 수 있습니다. Cherry-pick 전에 git show --stat <hash>를 통해 커밋이 어떤 파일을 변경했는지 확인하는 것이 좋습니다.

두 번째 규칙: cherry-pick 작업을 문서화하세요. -x 플래그를 사용하여 커밋 메시지가 원본 커밋에 대한 참조를 유지하도록 하세요. 이는 나중에 기록을 분석할 때 변경 사항의 출처를 이해하는 데 도움이 됩니다. -x가 없으면 cherry-pick이 일반 커밋처럼 보이며 그 출처는 git log --graph를 통해서만 확인할 수 있습니다.

세 번째 규칙: 너무 많이 분기된 브랜치 간의 cherry-pick은 피하세요. 커밋이 생성된 후 오랜 시간이 지나고 코드베이스가 크게 변경된 경우 충돌이 많고 복잡해집니다. 이러한 경우 대상 브랜치에서 수정 사항을 다시 구현하는 것이 수십 개의 충돌을 해결하는 것보다 시간이 덜 걸립니다.

• Cherry-pick은 외부 종속성 없이 자체 완결된 커밋에만.
• -x 플래그는 메시지에 커밋 출처를 문서화하기 위해 필수.
• 피하세요 코드베이스가 크게 다른 오래된 커밋에 cherry-pick 적용.
• CI/CD cherry-pick 후 빌드를 확인하세요: 충돌이 발생하지 않았더라도 코드가 컴파일되지 않을 수 있습니다.
• PR 코멘트 pull request를 만들 때 cherry-pick으로 전송된 커밋을 명시하세요.