브랜치를 합치는 방법은 여러 가지가 있습니다.
물론 merge로도 협업에 문제는 없지만 다양한 방법을 알아두면 능동적으로 활용 수 있습니다.
이 글을 통해 merge, rebase, 그리고 cherry-pick에 대해 정리해보겠습니다.
아래 자료들을 참고했습니다.
merge
merge의 종류에 관한 이전 포스팅을 참고하면 좋습니다.
협업에서 가장 일반적인 3-way merge 방식을 예로 들겠습니다.
$ git checkout master
$ git merge experiment
merge 결과, 변경 내용들을 담고 있는 merge 커밋(C5)이 생성됩니다.
또한 experiment 브랜치의 작업 내용도 히스토리에 그대로 남게 됩니다.
rebase
rebase는 이름 그대로 base(공통 조상)을 바꾼다는 의미입니다.
다시 동일한 예시를 보겠습니다.
$ git checkout experiment
$ git rebase master
rebase 실행 시 발생하는 과정입니다.
- 공통 조상(C2)으로 이동합니다.
- experiment 브랜치가 가리키는 커밋(C4)까지의 diff를 임시로 저장합니다.
- experiment 브랜치를 master 브랜치가 가리키는 커밋(C3)을 가리키게 만듭니다.
- 앞에서 저장해놓은 diff를 차례대로 적용합니다.
$ git checkout master
$ git merge experiment그리고 master 브랜치를 Fast forward merge 시킵니다.
결과적으로 코드는 merge와 rebase가 동일하게 합쳐집니다.
하지만 merge와 달리, 히스토리가 선형으로 정리되면서 깔끔해집니다.
주의사항
rebase는 히스토리를 선형으로 깔끔하게 정리해주는 장점이 있습니다.
하지만 기록의 목적으로 보면, rebase는 히스토리에 조작을 가하는 것과 같습니다.
그래서 일반적으론 merge를 사용하는 것이 좋습니다.
하지만 굳이 공개하고 싶지 않은 세세한 작업 내용 등은 rebase로 정리할 수 있습니다.
어떻게 쓸지는 상황에 막게 각자 판단하는 것이죠.
다만, 반드시 지켜야 할 규칙은 있습니다.
이미 원격 저장소에 올라간 커밋은 절대 rebase하지 말아야 합니다.
rebase는 push 하기 전에 히스토리를 정리하는 목적으로만 사용해야 합니다.
rebase는 기존 커밋을 옮기는 게 아닌, 내용만 동일한 새로운 커밋을 만들기 때문입니다.
그러므로 pull을 받게 되면 새로운 커밋으로 인식되어 충돌이 발생할 수 있습니다.
cherry-pick
히스토리 관리의 목적으로 cherry-pick을 활용할 수도 있습니다.
cherry-pick은 하나의 커밋만 rebase 하는 방식입니다.
$ git cherry-pick e43a6
cherry-pick을 실행하면 해당 커밋의 내용을 현재 브랜치에 동일하게 적용합니다.
다만 내용은 같지만 변경 시점은 다르기 때문에 커밋의 해시값은 달라지게 됩니다.