티스토리 뷰
동기들이랑 CS공부 같이 하자고 repository를 공유하기로 했다.
주마다 주제를 잡아서 공부하여 각자 브랜치에 commit 하고, main branch에는 발표한 사람만 pull request를 날려서 머지하기로 했다.
아래 그림처럼 각자 브랜치에는 개인 산출물이 쌓이고, main 브랜치(master)에는 발표를 맡은 사람의 산출물이 쌓여야 한다.
공용 레포지터리를 fork 해와서 cherry-pick등 내가 하고 싶은 거 다 해본 다음에,
정제된 commit을 공용 repository에 pull request를 날리려고 한다.
Git : Cherry-Pick
git의 cherry-pick은 commit 한개만 찍어서 merge 할 수 있다. pro git에서는 커밋 한 개만 Rebase 할 수 있는 명령으로 소개한다.
토픽 브랜치에 있는 커밋 중 하나만 고르거나 토픽 브랜치의 커밋이 하나 밖에 없을 때 rebase보다 유용하다.
아래와 같이 cherry pick을 실행하기 전 main 브랜치와 noonnoo라는 branch가 있다.
noonnoo의 d13d5ab9라는 커밋만 main 브랜치에 머지하고 싶다.
git cherry-pick 명령어로 merge 하고 싶은 특정 커밋을 main 브랜치로 merge 한다.
git cherry-pick <merge하고 싶은 커밋 ID>
위 명령을 실행하면 noonnoo 브랜치에 있던 커밋이 main 브랜치에 똑같이 반영된다. 하지만 변경한 시점이 다르므로 새 커밋의 SHA-1 해시값은 달라진다.
GitHub fork repository pull request 생성
위에서 cherry-pick 하여 반영한 커밋은 fork 해온 나의 repository, 그것도 로컬에서 작업한 것이기 때문에
이를 공용 repository에도 반영하려면 원격지로 push한 후에 pull request를 해야 한다.
로컬에서 작업한 내용을 git push 하여 원격지 레포지터리에도 반영해준다.
로컬에서 작업한 내용이 push 된 것을 확인하고, fork해온 원본 레포지터리에서 pull request를 생성한다.
Merge 승인받으면 원본 Repository에 반영된다.
Cherry pick은 또 언제 사용되는가?
* 팀 협업
각자의 코드를 작성하고 각자 방식대로 commit 한 내용 중 필요한 내용만을 반영하고 싶을 때 사용된다.
* Bug Hotfixes
중요한 버그 fix 내용이나 빠르게 반영해야 하는 내용이 있는 경우에 새로운 patch 내용을 빠르게 집어서 main으로 반영한다.
* 변경하고 싶지 않거나 손실된 커밋 복원
feature 브랜치가 오래되었고 main에 머지되지 않아 있는 상태에서 pull request가 닫히면, 옛날 커밋 중 하나를 다시 집어서 PR 할 수 있다.
[참고자료]
Scott Chacon and Ben Straub, Pro Git 2nd Edition, p.158