Git의 PR merge에 대해 알아보자

Merge Pull Request 녹색 버튼

이 버튼을 누르게 되면 선택된 두 브랜치를 머지하게 되는데요.

위의 스크린샷에서 확인할 수 있는 것처럼 GitHub 에서는 이렇게 두 개의 브랜치를 머지하는 총 3가지의 방법이 있습니다.

1. merge commit을 만들며 합치기
2. Squash and merge 하기
3. Rebase and merge 하기

각 방법들은 여러가지 장단점을 가지고 있습니다. 이제부터 각 병합 방법들이 어떤 방식으로 병합되고, 그 장단점은 무엇인지 알아보도록 하겠습니다.

 

Merge Commit을 만들며 합치기

'Merge commit' 방식은 두 브랜치의 변경 사항을 모두 유지하면서 병합합니다. 이 방식을 사용하면, 각 브랜치의 변경 사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합이 완료 됩니다.

장점과 단점

이 방식은 브랜치의 히스토리를 모두 유지하면서 변경 사항을 병합할 수 있다는 장점이 있습니다. 이를 통해 프로젝트의 진행 상황을 명확하게 이해하고 추적할 수 있습니다. 또한, 모든 커밋들의 커밋 아이디가 바뀌는 경우가 없기 때문에 다음에 다룰 squash와 rebase 방식에 비해서 비교적 사용이 쉽습니다.

단점은 커밋 히스토리가 복잡해질 수 있다는 것입니다. 다양한 브랜치에서 여러 작업이 이루어지면 커밋 로그가 빠르게 복잡해질 수 있습니다. 팀이 커지면 커질수록 이 복잡성은 빠르게 증가하게 됩니다.

 

Squash and Merge

'Squash and Merge'는 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식입니다. 이 방식은 각각의 커밋에서 발생한 모든 변경 사항을 병합 후에 하나의 새로운 커밋을 생성합니다. 아래의 예시에서는 3rd-4th-5th 커밋이 하나의 커밋 feature/f1으로 합쳐져서 병합이 된 것을 확인할 수 있습니다.

장점과 단점

이 방식은 커밋 히스토리를 간단하게 유지할 수 있단 장점이 있습니다. 이로 인해 각 커밋이 특정 Pull Request를 대변하게 되고, 그 의미를 이해하기 쉽게 됩니다. 다시 말해서 커밋 하나하나가 완성된 기능을 의미하게 됩니다. PR에서 발생한 자잘한 문제들을 숨기고, 그 PR에서 가장 중요하고 필요했던 내용들만 압축하여 담게 됩니다.

단점은 작업의 상세한 이력을 잃게 됩니다. 각 커밋에 대한 개별적인 맥락이나 작업자의 정보 등이 포함되지 않기 때문에 추후 문제 해결이 어려울 수 있습니다. 또한 기존의 작업 커밋의 아이디들이 하나로 합쳐지며 사라지고 새로운 커밋 아이디가 생성되기 때문에 여러명이서 해당 브랜치를 기반으로 작업을 수행하고 있었다면 병합이 이뤄지는 경우 복잡한 문제를 야기할 수 있습니다.

물론 squash 방식을 사용한다고 해서 모든 커밋 내역이 날아가는 것은 아닙니다. Git 자체가 아닌 GitHub에는 해당 커밋 기록들이 모두 남아있기 때문에 Pull Request를 검색해서 해당 작업의 커밋 히스토리를 확인 할 수 있습니다.

 

Rebase and Merge

'Rebase and Merge'는 현재 브랜치를 target 브랜치에 재위치(rebase)시킨 후 병합하는 방식입니다. 이는 target 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓는 것과 같습니다. 이렇게 되면 커밋 히스토리는 선형적으로 유지됩니다.

장점과 단점

이 방법은 깨끗하고 선형적인 커밋 히스토리를 만들어 준다는 장점이 있습니다. 이로 인해 히스토리 파악 및 코드의 변화 이해가 더욱 쉬워질 수 있습니다.

단점은 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있다는 점입니다. 이는 특히 브랜치가 크게 분기된 경우에는 복잡하고 어려울 수 있습니다. 여러 개발자가 동시에 작업을 수행한 경우에는 rebase 방식이 복잡한 충돌을 일으킬 수 있습니다.

추가로, PR별로 다른 기능으로 나뉘어 있던 작업 이력이, 하나의 선형적인 히스토리로 합쳐지는 단점이 있습니다. 다시 말하면, 특정 기능이 어디서부터 어디까지의 커밋으로 구현되었는지 알기 어려워진다는 뜻이죠.

 

그 결과는?

사실 코드 상의 결과는 3가지 방식 중 어떤 것으로 하더라도 전혀 달라지지 않습니다. 3가지 중 아무거나 선택하고 머지 버튼을 눌러볼까요?

다음과 같은 이미지가 떴습니다. 이후 main 브랜치로 이동해보면 README.md가 잘 수정되어 있는 것을 확인 할 수 있습니다.

 

마무리

다양한 머지 방법에 대해서 알아봤는데요. git-server를 호스팅하는 각 서비스 업체마다 제공하는 기능들이 다소 다를 수 있습니다. 각 방법의 장단점을 잘 알아 두고, 머지 방법을 통일하는 것이 협업할 때 혼란을 줄일 수 있습니다.

제가 추천드리는 방법은 가장 먼저 머지 커밋을 만드는 방법으로 Git을 활용해 보시고, 추후 프로젝트가 규모가 커져, 머지 커밋만으로 관리가 어려울 때, squash나 rebase 방식 등을 활용해서 커밋 이력들을 정리해 보세요. 목적을 고려해서 팀원들과 함께 머지 방법을 고민해 보시길 바랍니다.