스쿼시, 머지, 리베이스

머지 방법에는 크게 세 가지가 존재합니다.
스퀴시 머지(Squash Merge), 머지 커밋(Merge Commit), 그리고 리베이스 앤 머지(Rebase and Merge)입니다.
Git을 사용하는 대부분의 팀은 이 세 가지 중 하나, 혹은 조합된 전략을 선택해 사용하고 있습니다.

흥미로운 점은, 어느 전략이 "정답"이라고 합의된 경우는 거의 없다는 것입니다.
같은 Git을 사용하고, 같은 기능을 개발하더라도 회사나 팀에 따라 머지 전략은 확연히 달라집니다.
그렇다면 왜 이런 차이가 발생하는 걸까요?

이는 단순히 Git 사용 취향의 문제가 아니라,
팀의 협업 방식, 배포 주기, 장애 대응 전략, 그리고 변경 이력을 바라보는 관점이 다르기 때문입니다.

이 글에서는 세 가지 머지 방식이 각각 어떤 특징을 가지는지 살펴보겠습니다.

1️⃣ Squash Merge (스퀴시 머지)

스쿼시 머지는 개별 커밋 히스토리는 보존하지 않고, 변경 결과를 하나의 커밋으로 압축하여 병합하는 방식입니다.

그림으로 대략적으로 표현하면 위와 같은 형태가 됩니다.
하위 브랜치에서 여러 커밋으로 작업된 변경 사항을, 상위 브랜치에는 하나의 커밋으로 압축하여 반영합니다.
이 과정에서 작업 중 생성된 개별 커밋 히스토리는 상위 브랜치에 그대로 남지 않습니다.

스쿼시 머지의 핵심은 여러 커밋으로 나뉘어 있던 작업 과정을 하나의 결과 커밋으로 재구성한다는 점입니다.
이로 인해 세부적인 커밋 단위로의 롤백은 사실상 불가능하지만, 압축된 결과 커밋 단위의 롤백은 가능합니다.

상위 브랜치에는 압축된 결과 커밋만이 남기 때문에, 이후에 살펴볼 머지 커밋 방식과 비교했을 때 히스토리가 훨씬 단순하고 읽기 쉬운 구조를 제공합니다.

이렇게 어디에 머지가 되었는지 알 수 있죠. 하지만 세부적인 커밋 내용들은 확인하기 어려워 보입니다. 다른 것들도 함께 확인해 보겠습니다.

2️⃣ Merge Commit (머지 커밋)

머지 커밋은 하위 브랜치에서 생성된 개별 커밋 히스토리를 그대로 보존한 채, 상위 브랜치와의 병합 지점을 나타내는 별도의 머지 커밋을 생성하는 방식입니다.
이를 통해 각 커밋의 작업 흐름과 브랜치 간의 병합 시점을 명확하게 추적할 수 있습니다.

역시 그림으로 표현하면 위와 같은 형태로 나타낼 수 있습니다.
이 방식은 스쿼시 머지와 달리, 여러 커밋을 하나의 커밋으로 압축하지 않고 하위 브랜치의 개별 커밋 히스토리를 그대로 유지한 채 병합을 수행합니다. 이 과정에서 상위 브랜치에는 브랜치 병합을 나타내는 머지 커밋이 함께 생성됩니다.

이로 인해 병합 이후에도 세부적인 커밋 단위로의 롤백이 가능하며, 작업 과정과 변경 이력을 보다 명확하게 추적할 수 있습니다.

상위 브랜치에는 병합된 모든 커밋 기록과 병합 시점이 함께 남기 때문에, 운영 관점에서 안정성과 추적성이 높은 병합 방식이라고 볼 수 있습니다.

이렇게 y자형태로 저장이 된다는 사실을 알게 되었고 무엇보다 각 커밋히스토리도 확인이 가능합니다.

3️⃣ Rebase and Merge (리베이스 앤 머지)

마지막 방법은 리베이스(Rebase)입니다. 사실 이 방식은 엄밀히 말해 병합을 수행하는 방식이라기보다는, 커밋 히스토리를 재구성하는 방식에 가깝습니다. 리베이스는 하위 브랜치의 커밋들을 상위 브랜치의 최신 커밋 뒤에 다시 쌓아 올리기 때문에, 별도의 머지 커밋이 생성되지 않습니다. 이로 인해 히스토리는 직선 형태로 정리되지만, 브랜치가 병합되었다는 '사건' 자체는 기록으로 남지 않게 됩니다.

이러한 특성 때문에 일부 회사에서는 리베이스 사용을 제한하거나 금지합니다. 병합 시점과 브랜치 간 흐름을 명확히 추적하기 어렵고,
히스토리가 재작성되면서 협업 환경에서 혼란이나 사고로 이어질 수 있기 때문입니다.

그림으로 표현하면 위와 같은 형태가 됩니다. 이 방법의 경우, 브랜치 1에서 상위 브랜치로 병합되었다는 머지 커밋이 생성되지 않습니다.
즉, 히스토리 상에는 브랜치가 분기되었다가 다시 합쳐졌다는 기록이 남지 않습니다. 이로 인해 공유 브랜치에서 해당 방식을 사용할 경우,
어떤 브랜치가 언제 병합되었는지, 혹은 병합이 발생한 지점이 어디인지를 히스토리만으로는 파악하기 어렵다는 문제가 존재합니다.

그래서 리베이스 방식은 협업 브랜치보다는, 개인이 관리하는 개발 브랜치에서 커밋 히스토리를 정리하기 위한 용도로 주로 사용됩니다.

요렇게 상위 브랜치에서 작업은 하지 않았지만 마치 작업이 된 것처럼 보이네요

 

마무리

기존에는 머지 커밋만 병합 방법인 줄 알았는데 다양한 방식의 병합 방식들이 있었습니다. 스쿼시 머지, 머지 커밋, 리베이스 머지가 있습니다. 스쿼시 머지는 병합된 내용을 하나의 커밋내용으로 보여준다는 특징을 가지고 있고 빠르게 git 히스토리를 읽을 때 유리할 거라 생각이 되어 집니다. 그리고 머지 커밋은 커밋 히스토리를 유지한 채 병합이 된다는 특징이 있습니다. 히스토리를 면밀하게 확인할 수 있기 때문에 꼼꼼하게 git을 관리할 수 있을 거 같습니다. 마지막으로 리베이스 머지가 있습니다. 이 방법은 병합된 내용을 하위 브랜치의 커밋 내용들과 똑같이 보여준다는 특징을 가지고 있습니다. 머지 커밋이 없기 때문에 히스토리 상에서 병합 이벤트를 식별하기 어렵습니다. 그렇기 때문에 협업 방법으로는 사용하지 않는 것이 좋다고 생각합니다. 지금까지 머지 방법들에 대해 알아봤는데요. 각자의 상황에 맞는 병합 방법을 선택하는 것이 매우 중요하다고 생각합니다.