커밋 하나만 떼어 오고 싶을 때, git cherry-pick이 정답일까
브랜치를 나눠 작업하다 보면 "이 브랜치에 있는 이 커밋 하나만 지금 내 브랜치로 가져올 수 없을까?" 하는 상황이 꼭 생깁니다. merge를 쓰면 브랜치 전체 히스토리가 따라오고, rebase는 순서를 통째로 바꿔야 하니까 부담스럽죠. 이럴 때 사용하는 명령어가 바로 git cherry-pick입니다. cherry-pick은 다른 브랜치에서 원하는 커밋 하나(또는 여러 개)를 골라 현재 브랜치에 복사해 오는 기능입니다. 단, 이 과정은 단순 복사일 뿐 원본 커밋과 새로운 커밋의 해시값은 완전히 달라지며, 히스토리가 중복될 수 있다는 점을 미리 알아두어야 합니다.
cherry-pick은 어떻게 동작하나요 — 복사와 붙여넣기의 정확한 원리
git에서 cherry-pick을 실행하면, 선택한 커밋이 변경한 내용(diff)을 현재 브랜치에 적용한 뒤 새로운 커밋을 만듭니다. 다시 말해, 원본 브랜치에 있던 커밋을 '잘라내서 옮기는' 게 아니라 동일한 변경 사항을 지금 브랜치에 복사해서 새 커밋으로 남기는 방식입니다.
예를 들어 master 브랜치에서 작업 중인데, record 브랜치에 있는 update b.txt file이라는 커밋만 당장 필요하다고 가정해 보죠. 이때 다음과 같이 입력하면 됩니다.
git cherry-pick <해당 커밋의 해시>
그러면 record 브랜치에 있던 그 커밋의 변경 내용이 master 브랜치에 그대로 반영되고, 새로운 커밋이 하나 생깁니다. 로그를 확인해 보면 커밋 메시지는 같지만 해시값이 다른 것을 볼 수 있습니다.
이 과정에서 자동으로 커밋이 만들어지는데, 만약 자동 커밋을 원하지 않는다면 --no-commit 옵션을 붙이면 됩니다. 이 옵션을 쓰면 변경 사항만 스테이징된 상태로 남기 때문에, 직접 커밋 메시지를 수정하거나 추가 작업을 한 뒤에 커밋할 수 있습니다.
언제 cherry-pick을 써야 할까 — 실전에서 유용한 세 가지 상황
cherry-pick은 모든 상황에서 좋은 도구는 아닙니다. 오히려 남용하면 커밋 히스토리가 꼬이고, 같은 내용의 커밋이 여기저기 흩어져 관리가 어려워집니다. 그렇다면 어떤 경우에 진가를 발휘할까요?
1. 긴급 버그 픽스를 다른 브랜치에 반영할 때
운영 브랜치(main)에서 발견된 긴급 버그를 hotfix 브랜치에서 수정했습니다. 그런데 개발 중인 feature/login 브랜치에도 같은 수정이 필요하다면? 이때 feature/login 브랜치로 체리픽을 하면 merge나 rebase 없이 버그 픽스만 선택적으로 가져올 수 있습니다.
2. 특정 기능만 다른 브랜치로 옮기고 싶을 때
feature/signup 브랜치에서 회원가입 로직을 구현하다 보니, 로그인 브랜치에서 작업한 유효성 검사 함수가 필요해졌습니다. merge를 하면 로그인 브랜치의 모든 커밋이 따라오지만, cherry-pick을 쓰면 그 함수를 추가한 커밋 하나만 골라서 가져올 수 있습니다.
3. 잘못 브랜치에 커밋했을 때 되살리기
실수로 master에 커밋해야 할 내용을 develop 브랜치에 커밋해 버렸습니다. 이럴 때는 해당 커밋을 master로 체리픽 한 뒤, 원본 브랜치(develop)에서는 git reset이나 git revert로 그 커밋을 제거하면 됩니다.
다만, 이미 팀원들과 공유된 브랜치라면 reset보다 revert를 권장합니다. reset은 히스토리를 강제로 삭제하기 때문에 협업 중인 저장소에서는 문제를 일으킬 수 있습니다.
cherry-pick 사용 시 반드시 알아야 할 주의점
cherry-pick은 편리하지만, 몇 가지 함정이 있습니다. 아래 내용을 미리 숙지하지 않으면 예상치 못한 충돌이나 히스토리 오염을 겪을 수 있습니다.
-
충돌(conflict)은 언제든 발생할 수 있습니다.
가져오려는 커밋이 현재 브랜치의 파일과 같은 부분을 수정했다면, merge 때와 마찬가지로 충돌이 생깁니다. 이때는 수동으로 충돌을 해결하고git cherry-pick --continue로 진행하거나,--abort로 취소해야 합니다. -
커밋이 중복될 위험이 있습니다.
이미 현재 브랜치에 반영된 변경 사항을 다시 체리픽 하면, 동일한 내용이 커밋 두 개로 남게 됩니다. 히스토리가 불필요하게 길어지고, 나중에 누가 봤을 때 혼란을 줄 수 있습니다. 체리픽 전에git log로 현재 브랜치에 해당 변경이 이미 있는지 꼭 확인하는 습관이 필요합니다. -
커밋 단위가 클수록 체리픽은 고통스러워집니다.
하나의 커밋에 여러 기능의 변경 사항이 섞여 있으면, 원하는 부분만 떼어 오기 어렵습니다. 충돌이 나도 해결 범위가 너무 넓어 merge와 다를 바 없게 됩니다. '하나의 커밋 = 하나의 기능' 원칙을 지키는 팀일수록 체리픽을 유용하게 쓸 수 있습니다. 이 점은 팀 내 커밋 컨벤션과도 연결되므로, 같이 협의해 두는 것이 좋습니다.
자주 묻는 질문
Q. cherry-pick과 merge의 차이는 무엇인가요?
merge는 두 브랜치의 전체 히스토리를 합쳐 새로운 merge 커밋을 만듭니다. 반면 cherry-pick은 특정 커밋 하나(또는 여러 개)만 선택적으로 가져와서 새로운 개별 커밋으로 추가합니다. merge는 '브랜치 전체'를 대상으로 하고, cherry-pick은 '커밋 단위'로 동작한다고 이해하면 쉽습니다.
Q. 여러 개의 커밋을 한 번에 체리픽 할 수 있나요?
가능합니다. 커밋 해시를 공백으로 구분해서 여러 개를 나열하거나, 다음과 같이 범위를 지정할 수 있습니다.
git cherry-pick A..B # A 이후부터 B까지의 커밋 (A는 포함 안 됨)
git cherry-pick A^..B # A부터 B까지의 커밋 (A 포함)
단, 연속된 커밋이라도 현재 브랜치와의 관계에 따라 충돌이 발생할 수 있으니 주의해야 합니다.
Q. cherry-pick 한 커밋을 되돌리려면 어떻게 하나요?
일반 커밋과 마찬가지로 git revert를 사용하면 됩니다. 체리픽으로 추가된 커밋의 해시를 git revert <해시> 형태로 입력하면 해당 변경 사항을 취소하는 새로운 커밋이 만들어집니다. git reset도 가능하지만, 이미 푸시된 브랜치라면 revert가 안전합니다.