cherry-pick이란?

브랜치간에 특정 커밋을 병합하고 싶지만 모두 병합하지 않으려면 git cherry-pick가 유용합니다.
이 명령은 커밋을 노브하고 현재 브랜치에 추가합니다.

　 　

예를 들어 위 그림과 같은 장면에서 브랜치 a에 브랜치 b의 커밋 A, B만을 가져오고 싶다고 합니다.
이때,

git checkout a
git merge b

그렇다면 분기 b의 모든 커밋을 캡처합니다.
cherry-pick를 사용하면 다음과 같이 브랜치 b의 특정 커밋을 브랜치 a로 가져올 수 있습니다.

git checkout a
git cherry-pick Aのコミットid Bのコミットid

실제로 사용한 장면

cherry-pick를 사용한 구체적인 장면에 대해서 참고 정도로 이야기합니다.
개발 시에 다음과 같은 흐름을 취하고 있었습니다.


일의 발단은 개발을 마친 브랜치를 push하고 staging에 풀 요청을 만들 때 충돌을 일으킨 것입니다.
GitHub에서 해당 부분을 확인하면 1행 수정하면 해소되는 것이었기 때문에 GitHub에서 직접 충돌을 해소하고 풀 요청을 다시 보낼 수 있는 기능을 사용했습니다.
그 후, 검증에서 버그가 발견되었기 때문에, 다시 개발 환경에서 코드를 수정해, push했는데 리모트와 로컬로 커밋에 차이가 있기 (위해)때문에 pul 하고 나서 push 하도록(듯이) 분노됩니다.
충돌이 발생했을 때 GitHub에서 코드를 수정했기 때문에, 여기는 지시에 따라 pull하고 merge했습니다.

그러나 여기에서 merge한 내용을 확인해 보면, 자신이 GitHub에서 수정한 파일 이외의 파일에 관한 변경이 대량으로 포함되어 있는 것을 발각했습니다.
커밋 로그를 추적해 보면, 아무래도 GitHub상에서 충돌을 수정했을 때에 一度stagingをmergeして、競合箇所を編集しプルリクエストを作成する 라는 처리가 행해지고 있었던 것 같습니다.
GitHub상에서는 GUI로 조작을 하고 있었기 때문에 부주의한 나는 포치포치 눌러 버려 눈치채지 않는 사이에 staging를 merge해 버렸습니다.

staging을 merge하면 무엇이 곤란한가 하면, staging에서 검증중이었던 다른 브랜치로의 변경을 대량으로 받아들여 버려, 개발시에 생각하지 않는 버그가 발생할 가능성이 있습니다.
이때, 개발을 하고 있던 브랜치의 커밋 로그는 자신의 커밋과 타인의 커밋이 혼재해 아래의 그림과 같이 되어 있었습니다.
　　　　　
git revert 뭔가를하고 원래 상태로 되돌리는 것도 생각했지만 커밋 로그가 거칠어 보였기 때문에 (실제로는 더 혼재했습니다) 필요한 커밋만 픽업하고 싶습니다. .
여기 cherry-pick의 차례입니다.

먼저 개발 환경에서 master에서 브랜치를 다시 시작합니다.

git checkout master
git checkout -b develop-hoge-new

그런 다음 문제의 분기(여기서는 develop-hoge라고 합니다.)로 이동하여 커밋 로그를 확인합니다.

git checkout develop-hoge
git log

필요한 커밋의 ID를 확인하고 새 브랜치로 cherry-pick합니다.

git checkout develop-hoge-new
git cherry-pick Aのコミットid Bのコミットid Eのコミットid

그러면 develop-hoge-new 브랜치에 필요한 커밋만을 캡처할 수 있습니다.

　　　　　　

그리고는 다시 푸시합니다.

충돌한 부분에 대해서는 경쟁한 상대의 브랜치가 릴리스된 후에 로컬의 master 브랜치에서 master를 pull 해 develop-hoge-new에 merge 해 해 봅시다.

참고문헌

입문 git