(git) git cherry-pick 단일 커밋 이식
✨ 개요
서비스 운영 중에 “운영에만 급하게 반영해야 하는 버그 수정”이 생기면, 전체 브랜치를 다 merge 하기는 부담스럽고 딱 그 커밋 하나만 가져오고 싶을 때가 있습니다. 이 때 사용하는 Git 기능이 바로 git cherry-pick입니다.
이 글에서는 단일 커밋을 다른 브랜치로 이식해서 핫픽스/릴리즈 브랜치를 관리하는 방법을 정리합니다.
1. 요약
git cherry-pick은 특정 커밋 하나(또는 여러 개)를 다른 브랜치에 “다시 적용”하는 명령이다.- 전체 브랜치를 merge 하지 않고, 원하는 커밋만 골라서 릴리즈/핫픽스 브랜치에 반영할 수 있다.
- 충돌이 발생할 수 있으므로, conflict 해결 → git cherry-pick –continue 흐름을 알아두어야 한다.
- 너무 남발하면 히스토리가 복잡해지고, 동일 변경이 여러 번 들어가는 문제(중복 커밋)가 생길 수 있어 주의가 필요하다.
2. 왜 cherry-pick이 필요한가? (핫픽스/릴리즈 시나리오)
- 일반적인 Git 브랜치 전략(예: Git Flow)에서 이런 상황이 자주 발생합니다.
- develop 브랜치: 다음 버전을 위한 개발용 브랜치
- release/1.2.0 브랜치: 현재 배포 준비 중인 릴리즈 브랜치
- main 또는 master 브랜치: 운영 배포 브랜치
- 예시 상황
- develop에서 버그 픽스 커밋을 만들었다.
- 그런데 지금 당장 운영 쪽(main 또는 release/1.2.0)에도 같은 수정이 급히 필요하다.
- 그렇다고 develop 전체를 merge 하자니, 아직 준비 안 된 기능들이 같이 섞여 들어온다.
이럴 때 해당 버그 수정 커밋만 골라서 릴리즈/핫픽스 브랜치로 이식하는 게 git cherry-pick의 역할이다.
3. git cherry-pick이란? (개념 정리)
git cherry-pick은 특정 커밋의 변경 내용을 현재 체크아웃된 브랜치 위에 “새로운 커밋으로 다시 적용”하는 명령어입니다.
- 단일 커밋을 다른 브랜치에 복사해서 반영하는 것과 비슷하다.
- 원본 커밋과 내용은 같지만, 커밋 해시(commit hash)는 다르다.
- merge와 달리, 브랜치 간의 공통 조상/이력 관계를 따지지 않고 해당 커밋 하나만 뽑아서 적용한다.
4. cherry-pick 준비: 커밋 ID 찾기
먼저 이식하고 싶은 커밋의 해시를 찾아야 합니다.
# 예: develop 브랜치에서 버그 픽스 커밋 확인
git checkout develop
git log --oneline
로그
a1b2c3d4 [bugfix] 로그인 실패 시 NPE 해결
9e8f7a6b [feature] 프로필 편집 화면 추가
5. 단일 커밋 cherry-pick으로 핫픽스/릴리즈 반영하기
이제 해당 커밋을 릴리즈 브랜치로 이식해 보겠습니다.
# 릴리즈 브랜치로 이동
git checkout release/1.2.0
# cherry-pick 실행
git cherry-pick a1b2c3d4
# 원격에 푸시
git push origin release/1.2.0
- Git은 a1b2c3d4 커밋의 변경 내용을 현재 브랜치(release/1.2.0) 위에 새로운 커밋으로 적용한다.
- 충돌이 없다면 자동으로 커밋까지 완료된다.
- 이제 release/1.2.0 브랜치에도 해당 버그 수정이 반영되었고, 바로 배포 파이프라인으로 흘려보낼 수 있습니다.
6. 여러 개 커밋 한 번에 cherry-pick 하기
A (이전 커밋)
B (버그 수정 1)
C (버그 수정 2)
D (버그 수정 3)
git cherry-pick B^..D
git cherry-pick a1b2c3d4 e5f6a7b8 9c0d1e2f
- B^..D는 “B의 이전 커밋부터 D까지”라는 의미의 범위이고, cherry-pick에서는 이 범위 내의 커밋(B, C, D)이 순서대로 적용된다.
- 연속되지 않은 커밋들을 순서대로 적용하고 싶다면, 커밋을 나열하면 됩니다.
7. cherry-pick 사용 시 주의할 점 & 베스트 프랙티스
7.1 너무 남발하면 히스토리가 꼬인다
- 동일한 변경이 여러 브랜치에 서로 다른 커밋 해시로 존재하게 된다.
- 나중에 merge 할 때 “어? 이 변경은 이미 들어가 있지 않나?”라는 혼란이 올 수 있다.
- 가능한 한 핫픽스/중요 버그에만 한정해서 사용하는 것이 좋다.
7.2 merge 커밋 cherry-pick은 신중하게
- merge 커밋을 그대로 cherry-pick 하면, 관련된 여러 변경들이 한 번에 들어와 예기치 않은 사이드 이펙트가 생길 수 있다.
- 웬만하면 단일 기능/단일 버그의 “단일 커밋”을 cherry-pick 하는 방식으로 관리하는 것이 안전하다.
7.3 공통 기준 브랜치를 정해두기
팀 내 규칙 예시:
- 버그 수정은 항상 가장 하위 레벨 브랜치(예: release/1.2.0 또는 main)에서 먼저 한다.
- 그 다음 위쪽 브랜치(develop 등)에 merge 해서 올라온다.
- 특별한 사유가 아니라면 위쪽 브랜치에서 cherry-pick 해서 아래로 내리는 패턴을 줄인다. (중복 반영/충돌 리스크 감소)
7.4 커밋 메시지에 출처 남기기
나중에 추적하기 쉽게 커밋 메시지에 출처를 남기는 것도 좋습니다.
예:
- cherry-pick from develop: a1b2c3d4
- [hotfix] 로그인 NPE 수정 (cherry-picked from a1b2c3d4)
8. 결론
- git cherry-pick은 단일 커밋(또는 몇 개 커밋)을 다른 브랜치 위에 복사해서 적용하는 도구다.
- 핫픽스/릴리즈 브랜치 관리에서 “지금 당장 이 버그 수정만 필요할 때” 매우 유용하다.
- 다만 히스토리 복잡도와 충돌 가능성을 고려해서,
- 핫픽스/중요 버그 중심으로 제한적으로 사용하고
- 커밋 출처를 명확히 남기는 것이 좋다.