git cherry-pick 사용법 / 원하는 커밋만 쏙 골라 가져오기

git cherry-pick 사용법, 다른 브랜치의 특정 커밋만 쏙 골라 가져오는 4단계 가이드

팀 협업을 하거나 브랜치를 나누어 개발하다 보면, 다른 브랜치 전체를 머지(Merge)하기에는 부담스럽고 딱 하나의 버그 수정 커밋이나 특정 기능 커밋만 내 브랜치로 가져오고 싶은 순간이 있습니다. 이때 사용하는 Git의 마법 같은 명령어가 바로 git cherry-pick입니다.

결론부터 말씀드리면, git cherry-pick [커밋해시] 명령어를 사용하면 다른 브랜치의 특정 커밋만 현재 브랜치로 복사해 올 수 있습니다. 다만, 체리피킹은 편리한 만큼 커밋 간의 의존성을 고려하지 않으면 치명적인 코드 충돌이나 빌드 에러를 유발할 수 있습니다. 실무에서 안전하게 특정 커밋만 골라 담는 실전 점검 순서와 충돌 대처법을 정리해 드립니다.

자주 보이는 증상

• develop 브랜치에서 핫픽스(Hotfix) 성격의 버그를 고쳤는데, 당장 내일 배포할 release 브랜치에 전체 머지 없이 그 버그 수정 코드만 쏙 넣고 싶음
• 실수로 작업 브랜치를 헷갈려서 다른 브랜치에 커밋을 생성해 버려, 올바른 브랜치로 해당 커밋만 이동시켜야 함
• 체리피킹을 실행했더니 터미널에 Conflict 에러가 나면서 이전 코드가 꼬이고 빌드가 깨짐

왜 이런 문제가 생길까

1) 커밋 간의 유기적인 의존 관계 (Dependency)

Git의 커밋들은 대개 독립적이지 않고 앞선 커밋들의 코드 변경 사항을 기반으로 작동합니다. 예를 들어 A 커밋에서 새로운 공통 함수를 정의하고 B 커밋에서 그 함수를 가져다 썼다면, A를 빼놓고 B 커밋만 체리피킹했을 때 존재하지 않는 함수를 호출하게 되므로 프로그램이 즉시 터지거나 심각한 충돌이 발생합니다.

2) 커밋 해시(Hash)의 복제와 히스토리 파편화

체리피킹은 원래 커밋을 그대로 잘라 붙이는 게 아니라, 내용물(변경 사항)만 똑같이 복사해 내 브랜치에 완전히 새로운 커밋 객체로 생성하는 것입니다. 따라서 알맹이는 같아도 '커밋 해시' 번호가 새로 부여됩니다. 이를 너무 남발하면 나중에 두 브랜치를 통째로 머지할 때 Git이 같은 내용의 커밋을 중복으로 인식해 대량의 충돌을 일으킬 수 있습니다.

git cherry-pick 사용법 해결 방법

1단계. 가장 먼저 확인할 부분: 가져올 커밋의 정확한 고유 해시(Hash) 찾기

• 무엇을 확인하는지: 커밋이 들어있는 상대 브랜치(예: develop)의 로그를 git log --oneline develop 명령어로 조회하여, 내가 가져오고자 하는 특정 커밋의 7자리 고유 해시값(예: a1b2c3d)을 찾아 복사합니다.
• 왜 먼저 확인해야 하는지: 엉뚱한 커밋 해시를 지정해 실행하면 원치 않는 과거 코드가 덮어씌워져 이를 되돌리는 부가적인 수고(Hard Reset 등)가 필요하기 때문입니다.
• 확인 후 어떻게 판단하는지: 로그의 메시지를 꼼꼼히 읽고 내가 가져올 파일 변경이 포함된 정확한 커밋 해시를 식별했다면 다음 2단계로 이동합니다.

2단계. 다음 점검: 커밋을 적용할 '목적지 브랜치'로 안전하게 이동

• 무엇을 확인하는지: git switch release (또는 git checkout release)를 입력해 커밋을 받아올 브랜치로 이동한 후, git branch를 쳐서 현재 위치의 앞에 별표(*)가 올바르게 붙어있는지 최종 점검합니다.
• 왜 먼저 확인해야 하는지: 체리피킹은 '현재 내가 위치한 브랜치'를 기준으로 코드를 덮어쓰는 명령어입니다. 다른 브랜치에서 깜빡하고 명령어를 실행하면 엉뚱한 곳에 복사본 커밋이 박히게 됩니다.
• 확인 후 어떻게 판단하는지: 목적지 브랜치로 무사히 이동했고 워킹 디렉토리가 깨끗한 상태(Clean)라면 체리피킹을 실행할 준비가 된 것입니다.

3단계. 추가 조치: 체리피킹 실행 및 다중 커밋 적용

• 무엇을 확인하는지: 터미널에 git cherry-pick a1b2c3d를 입력합니다. 만약 여러 개를 한 번에 가져오고 싶다면 공백으로 구분하여 git cherry-pick a1b2c3d b2c3d4e를 입력하거나 연속된 범위(git cherry-pick 시작커밋^..끝커밋)를 지정합니다.
• 왜 먼저 확인해야 하는지: 충돌이 없다면 지정한 커밋의 변경 사항만 현재 브랜치에 완벽하게 스캔되어 새 커밋으로 자동 등록됩니다.
• 확인 후 어떻게 판단하는지: 실행 후 git log --oneline을 쳤을 때, 가져온 커밋 메시지가 최상단에 예쁘게 찍혀 있다면 성공입니다. 만약 잘못 가져왔다면 push 전이라는 전제하에 git reset --hard HEAD~1로 취소할 수 있습니다.

4단계. 그래도 안 되면 볼 부분: 체리피킹 충돌(Conflict) 해결

• 무엇을 확인하는지: 실행 후 CONFLICT 경고가 발생하면 git status로 충돌 파일을 파악한 뒤, 에러 구간(<<<, ===, >>>)을 정돈하고 git add [충돌파일] 후 git cherry-pick --continue를 입력합니다.
• 왜 먼저 확인해야 하는지: 가져오려는 커밋의 수정 부위가 현재 브랜치의 코드와 겹치거나 선행 커밋 코드가 누락되었을 때 발생하는 자연스러운 현상입니다. 일반 머지와 달리 마무리를 --continue 옵션으로 이어나가야 체리피킹 프로세스가 최종 종료됩니다.
• 확인 후 어떻게 판단하는지: 만약 코드가 너무 꼬여서 체리피킹하기 전 상태로 안전하게 롤백하고 싶다면 언제든지 git cherry-pick --abort를 입력해 시도 자체를 깨끗하게 무효화할 수 있습니다.

실전에서 자주 놓치는 부분

신입 개발자들이 실무에서 체리피킹을 쓸 때 가장 많이 놓치는 실수는 '코드가 깔끔하게 들어왔으니 바로 원격 저장소에 push해 버리는 것'입니다. 체리피킹은 특정 커밋만 '강제로' 복사해 오는 성격이 강하므로, 눈에 보이는 문법 충돌이 없었더라도 다른 소스코드와의 호환성이 깨져 프로젝트 전체 빌드가 실패할 수 있습니다. 커밋을 땡겨왔다면 push하기 전에 반드시 로컬 환경에서 프로젝트를 실행해 보거나 빌드 테스트(npm test, mvn test 등)를 직접 돌려 검증하는 프로세스를 거쳐야만 협업 시 빌드를 깨트리는 대형 사고를 막을 수 있습니다.

마무리

git cherry-pick 사용법은 브랜치 전체를 머지하기 어려운 급박한 핫픽스나 배포 상황에서 최고의 효율을 발휘하는 도구입니다. 급하게 특정 커밋만 무수히 가져와야 할 때는 이 흐름만 기억하세요.

1. git log --oneline 상대브랜치로 가져올 커밋의 7자리 해시 복사하기
2. git switch 목적지브랜치를 쳐서 내가 적용할 브랜치 위치가 맞는지 눈으로 꼭 확인하기
3. git cherry-pick [커밋해시] 실행하기
4. 충돌 발생 시 코드를 정돈하고 git add 한 뒤, git cherry-pick --continue로 끝맺음하기 (포기할 땐 --abort) 체리피킹은 브랜치 줄기를 합치는 정석이 아닌 '복사 패치'이므로 꼭 필요한 순간에만 신중하게 사용하는 습관을 들이시길 바랍니다.