Merge? Squash? Rebase? PR 병합 방식 제대로 이해하기

,

Github에서 Pull Request 리뷰가 끝나면 소스 브랜치를 타겟 브랜치에 병합합니다. 이때, 브랜치를 병합하는 방법은 아래 그림과 같이 세 가지가 있습니다.

PR 승인 후 병합하는 세 가지 메뉴

각각 어떻게 다르고 언제 사용해야할까요? 이번 포스트에서는 Pull Request 를 병합하는 세 가지 방법에 대해 알아 보겠습니다.

병합 전 원본 커밋 히스토리

Pull Request 를 병합하는 세 가지 방법

1. Create a merge commit

Create a merge commit

가장 기본적인 머지 방식입니다. 이 방법을 사용하면, 위 그림처럼 feature브랜치를 main 브랜치에 병합하는 머지 커밋(C11)이 생성되며, 두 브랜치가 하나로 합쳐집니다. 이 방식의 장점은 브랜치의 커밋 히스토리를 그대로 유지한 채 병합할 수 있다는 점입니다. 단점은 머지할 때마다 머지 커밋이 생성되서 병합이 반복될수록 커밋 히스토리가 복잡하고 보기 어려워질 수 있다는 점입니다.

2. Squash and merge

Squash and merge

이 방식은 여러 커밋을 하나로 압축(squash)해 단일 커밋으로 병합하는 방식입니다. 병합 후 커밋 히스토리가 매우 간결하고 명확해지는 것이 장점입니다. 하지만 각 커밋에 담긴 세부 내용이 사라지고, 문제가 발생했을 때 어떤 커밋에서 문제가 시작됐는지 또는 누가 작성했는지를 추적하기 어렵다는 단점도 있습니다.

3. Rebase and merge

Rebase and merge

리베이스로 병합하면 커밋히스토리를 일려로된 상태로 만들어 병합 합니다. 리베이스로 병합하면 아무리 많은 브랜치를 병합하더라도 일렬로된 깔끔한 커밋히스토리를 유지할 수 있습니다. 리베이스를 수행하면 브랜치의 모든 커밋을 다시 만들기 때문에 충돌 발생시 충돌 해결을 여러 단계에 걸쳐 해야할 수 있어 해결이 번거로울 수 있습니다.

PR을 어떤 방식으로 병합해야 할까?

방법은 팀별 상황에 맞게 선택하면 됩니다. 히스토리를 보존하는 것이 중요하고 병합시 커밋히스토리가 크게 복잡하지 않다면 “Create a merge commit” 방식을, PR에 포함된 커밋이 너무 많아 커밋 히스토리 관리가 어려운 경우에는 “Squash and merge” 방식을 권해드립니다. 이 방식의 단점인 개별 커밋 내역이 사라지는 문제는, 병합 시 머지 메시지에 주요 변경 사항을 간략히 요약함으로써 어느 정도 보완할 수 있습니다. 병합해야 할 브랜치가 많고, 커밋의 세부 내용을 최대한 유지하면서도 커밋 히스토리를 일렬로 정리된 간결한 형태로 유지하고 싶을 때“Rebase and merge” 방식을 사용하면 됩니다.

정리

이번 포스트에서는 Github의 Pull Request의 세 가지 병합 방법에 대해 알아 봤습니다. 다음시간에도 유익한 내용으로 찾아오겠습니다. 이상 깃에 미친 남자 깃미남 이었습니다.

👨🏻‍💻Git 지식이 +3 늘었다. 다음 포스트에서 또 만나요 🚀😄

연관 포스트

 


매주 1회 발행되는 Git 뉴스레터 구독하기

Git을 제대로 배우고 싶은 분들을 위해 책, 온라인 강의, 그리고 오프라인 실전 교육까지 다양한 형태로 준비했습니다. 여러분의 학습 스타일에 맞는 방식으로 Git을 제대로 배워보세요. 👇

Leave a Reply

Your email address will not be published. Required fields are marked *

Kakaotalk
Email
Phone
Phone
Email
Kakaotalk