사내에서 브랜치를 머지하기 위해 rebase 후 squash merge하는 전략을 쓰고있다. 즉 어떤 feature 브랜치가 이 master 브랜치에 머지되려면 rebase 후 CI 파이프라인을 통과한 다음 squash merge를 통해서 브랜치가 머지된다.
오늘은 여러 브랜치 머지 전략에 대해 간단히 설명하고, 각각을 쓰면서 내가 느꼈던 장단점에 대해 포스팅 해보고자 한다.
- Merge Commit
Merge Commit은 master와 피쳐 브랜치가 둘다 수정되었을 때 피쳐 브랜치의 commit 로그와 merge 로그가 동시에 기록된다. 이 경우 commit 로그는 commit 을 행한 순서대로 기록되며, merge log도 merge가 된 순서대로 기록된다.
Merge Commit은 커밋 순서와 머지 순서가 달라진다. 그래서 커밋 히스토리 관리 및 이해가 어렵다고 느꼈다.
- Rebase and Merge
Rebase and Merge 정책은 커밋 순서가 아니라 머지된 순서대로 커밋 로그가 기록된다. 즉 하나의 PR에 담긴 커밋 메시지가 다른 PR의 커밋 메시지와 섞이지 않게 된다. (즉 내가 해결하고자 한 이슈의 커밋들이 마스터에서 정렬되어 있다.) 이렇게 될 경우 커밋 로그가 굉장히 깔끔해진다는 장점이 있었다.
다만 쓰면서 느꼈던 단점은 내 PR에 커밋이 많은데 master와 머지하려고 할 때 conflict가 많다면 resolve하기 까다롭다는 단점이 있었다. 일례로 한 PR에 20개 정도 커밋이 있었는데, rebase하니까 커밋 step별로 conflict가 많이 나서 해결하는데 애를 먹은 경험이 있었다.
⇒ 사실 이럴 때는 이슈를 분리하는 것이 맞는 것 같다. 관리하게 편하게 이슈를 잘 분리하는 것도 일을 잘하는 방법이라고 생각한다.
- Squash and Merge
Squash and Merge 정책은 브랜치에 있는 모든 커밋들이 하나의 커밋으로 스쿼시되어 합쳐진다. 합쳐진 새로운 커밋의 제목은 PR제목이 되며, 새로운 커밋 안에는 그동안 수행했던 커밋 메시지들이 차곡차곡 기록되어 있다.
쓰면서 느꼈던 장점은 합쳐진 하나의 커밋 자체가 우리가 해결하고자 하는 이슈 하나를 의미하는 것이기 때문에 히스토리가 정말 깔끔하게 정리된다는 것을 느꼈다. 다만 이 전략의 경우 커밋 히스토리를 예쁘게 관리하기 위해서, PR제목을 신경써야 한다. (이건 서로 코드리뷰 할 때 잘 챙겨야 한다)
단점은 어떤 브랜치의 세부 커밋 단위로 코드 revert가 불가능 하다는 것이다.
위와 같은 단점이 있지만.. 사실 세부 커밋 단위가 문제가 생겨 해당 커밋만 revert하는 경우는 거의 없었다. 그 정도로 문제 파악이 된 경우라면 hotfix를 통해 해결하면 되고, 도저히 문제파악을 할 시간이 없으면 하나의 이슈 덩어리(squash commit)을 revert 시키면 대부분 해결되었다.
사내에서 서비스를 개발하고 운영하면서 rebase 후 squash merge하는 전략에 굉장히 만족하고 있다. 커밋 히스토리 관리가 용이해졌으며 핫픽스나 Revert할 때 대응하기 수월해졌다. 다만 커밋 단위의 atomic rollback이 필요한 경우는 rebase and merge 정책으로 전환을 고려해볼 수 있을 것 같다. (이건 이슈 관리 정책이나 프로젝트 성격마다 다를 것 같다.)
