다양한 Merge방식
Merge 방식에는 여러가지가 있다.
한 브랜치에서 다른 브랜치로 합치는 방법에는 Merge와 Rebase가 있다.
가장 먼저, Merge방식이다. Merge방식은 가장 많이 사용되는 병합이며 커밋 이력을 남길 때 사용한다. 그래서 커밋 히스토리가 지저분하다는 단점이 있다. Merge는 Fast-Forward방식과 Recursive방식으로 나뉜다.
기존 브랜치를 main, 새로운 브랜치를 develop라 표현하겠다. Fast-Forward Merge방식은 main에서 develop을 분기한 후, 새로운 커밋이 올라오지 않았을 때 develop의 변경 이력을 그대로 main으로 가져오는 것을 말한다. 그리고 Recursive Merge방식은 main에서 develop를 분기한 이후 main에 새로운 커밋이 생겼다면 develop은 최신이 아니다. 이 때 develop과 main을 공통 부모로 한 새로운 Merge commit을 생성하며, 이 방식을 Recursive Merge라 한다.
Squash & Merge는 여러 개의 커밋을 하나의 커밋으로 합치는 것을 말한다.
Rebase & Merge는, develop를 main에서 분기할 때의 커밋인 base를 다시 설정한다는 의미이다. base를 최신 main의 커밋으로 설정하는 것을 말한다.
어떤 방식을 사용해야 할까?
-
feature → develop 머지
Squash & Merge가 유용하다. feature브랜치에서 기능을 개발하기 위한 지저분한 커밋 내용을 하나의 커밋으로 묶어 develop에 병합하면서, develop에는 기능 단위로 커밋이 추가되도록 정리할 수 있다. feature에서 작업을 완료한 후, feature를 제거한다는 점을 떠올려 보면, feature브랜치의 커밋 히스토리를 모두 develop에 연관지어 남길 필요가 없다.
-
develop → main 머지
Squash&Merge하게 되면 커밋 이력이 모두 사라져, 특정 기능에서 문제가 생겼을 때 롤백할 수 없게 된다. main 브랜치 또한 Merge Commit을 남길 필요가 없기에 Rebase & Merge가 적합하다.
-
hotfix → develop / hotfix → main
Merge 또는 Squash & Merge. 히스토리가 모두 남아야 하는 경우 Merge, 아닌 경우 Squash&Merge 추천
Feature브랜치에서 develop과 master 둘 다 적용하고 싶을 때는 어떻게 해야할까?
- feature에서 develop로 머지 > develop에서 master로 머지
- 이 방식은 부적합하다. 왜냐하면, Develop의 모든 변경 사항이 Master로 머지가 될 텐데 그러한 플로우를 원하는 것이 아니다.
- feature > develop으로 머지 > feature에서 cherry pick하여 develop으로 가져가기
- master에 머지 후 pull rebase로 develop에 가져오기
- rebase를 사용할 경우, 기존의 커밋 히스토리를 변경하게 되어 공유하는 브랜치에서의 사용은 주의를 요한다.
- 또한, master에 먼저 변경사항을 적용하는 것은 리스크가 있는 행위이다.