git cherry-pick은 특정 커밋 하나 또는 몇 개의 변경만 현재 브랜치로 가져올 때 쓰는 명령입니다.
핵심은 브랜치 전체를 합치는 것이 아니라 필요한 커밋의 변경만 새 커밋으로 적용한다는 점입니다. 이 글은 Git 공식 문서를 기준으로 cherry-pick의 장점, hotfix 상황, conflict, 중복 커밋 위험을 정리합니다.
git cherry-pick을 한 문장으로 보면
cherry-pick은 다른 브랜치에 있는 특정 커밋의 변경 내용을 현재 브랜치에 적용합니다. 원본 커밋을 옮기는 것이 아니라 같은 변경을 담은 새 커밋을 만드는 흐름에 가깝습니다.
git switch release/1.2
git cherry-pick a1b2c3d이 명령은 `a1b2c3d` 커밋의 변경을 `release/1.2` 브랜치에 적용합니다. 새 커밋 해시는 보통 원본과 달라집니다.
merge와 무엇이 다를까
merge는 한 브랜치의 히스토리를 현재 브랜치와 합칩니다. cherry-pick은 브랜치 전체가 아니라 선택한 커밋의 변경만 가져옵니다.
- merge: 브랜치 흐름 전체를 합친다
- cherry-pick: 선택한 커밋의 변경만 적용한다
- merge는 히스토리 관계가 남고, cherry-pick은 같은 변경이 다른 커밋으로 복제될 수 있다
언제 cherry-pick이 유용할까
대표 상황은 hotfix입니다. main에는 이미 수정이 들어갔지만, 운영 중인 release branch에도 같은 수정이 급하게 필요할 수 있습니다.
git switch main
git log --oneline
git switch release/1.2
git cherry-pick 4f8a9c1또는 feature branch의 여러 커밋 중 문서 수정 하나만 먼저 가져오고 싶을 때도 사용할 수 있습니다. 다만 이런 상황이 반복되면 브랜치 전략 자체를 다시 봐야 할 수 있습니다.
conflict가 나면 어떻게 생각해야 할까
cherry-pick도 merge처럼 충돌이 날 수 있습니다. 원본 커밋이 기대하는 주변 코드와 현재 브랜치의 코드가 다르면 Git이 자동으로 적용하지 못합니다.
git cherry-pick 4f8a9c1
# 충돌 해결 후
git add .
git cherry-pick --continue
# 중단하려면
git cherry-pick --abort충돌 해결은 단순히 표시를 지우는 일이 아닙니다. 해당 변경이 현재 브랜치의 코드와 의미상 맞는지 테스트까지 확인해야 합니다.
위험은 중복 커밋과 추적 어려움
cherry-pick은 편하지만, 같은 변경이 서로 다른 커밋으로 여러 브랜치에 남을 수 있습니다. 나중에 merge할 때 이미 들어간 변경이 다시 보이거나, 어떤 브랜치에 어떤 수정이 들어갔는지 추적하기 어려워질 수 있습니다.
- 같은 버그 수정이 여러 커밋 해시로 존재한다
- release branch마다 수동 적용 이력이 생긴다
- 충돌 해결 방식이 브랜치마다 달라질 수 있다
- PR 리뷰에서 원래 맥락이 잘 보이지 않을 수 있다
실무 체크리스트
- 브랜치 전체를 합칠 상황인지 특정 커밋만 필요한 상황인지 먼저 구분한다
- hotfix나 release branch 보정처럼 이유가 분명할 때 사용한다
- cherry-pick한 원본 커밋을 PR 설명이나 이슈에 남긴다
- 충돌 해결 후에는 해당 브랜치 기준 테스트를 실행한다
- 반복적으로 필요하다면 브랜치 전략이나 릴리스 흐름을 점검한다
정리
git cherry-pick는 이름만 외우는 것보다 어떤 문제를 줄이기 위한 도구인지 보는 편이 좋습니다. 이 글에서는 공식 문서 기준으로 핵심 개념, 자주 하는 실수, 실무 판단 기준을 함께 정리했습니다.
함께 보면 좋은 내부 글은 git rebase와 merge 차이, Dockerfile layer cache는 왜 중요할까, JWT access token과 refresh token은 왜 나눌까입니다. 외부 기준은 Git Documentation – git-cherry-pick, Git Documentation – git-merge, Git Book – Branching and Merging를 확인했습니다.
