Git Merge 전략: Merge, Rebase, Squash로 복잡한 히스토리 정리하기

병합(Merge)을 수행하는 세 가지 방법

Merge, Squash, Rebase 세 가지 방법에 대해 특징과 적용 상황을 간단히 정리해 보겠습니다.

1. Merge Commit

기본 병합 방법으로, 두 브랜치를 병합하면서 별도의 병합 커밋이 생성됩니다.

장점 : 각 브랜치의 히스토리를 온전히 보존할 수 있습니다.
단점 : 커밋 그래프가 복잡해질 수 있습니다.
적용 상황 : 병합 후에도 브랜치 간 작업 내용을 추적해야 하는 경우. 예를 들어, 여러 개발자가 동시에 작업한 내용을 통합할 때 유용합니다.

2. Squash Merge

브랜치를 병합하면서 모든 커밋을 하나의 커밋으로 합칩니다.

장점 : 여러 커밋을 하나로 합치기 때문에 그래프가 깔끔하고 가독성이 좋습니다.
단점 : 여러 커밋이 하나로 합쳐지기 때문에 상세한 변경 내역을 추적하기 어려울 수 있습니다.
적용 상황 :

• PR(Pull Request) 코드 리뷰 시 자잘한 수정사항이 많을 때:
  예를 들어, 기능 개발을 완료하고 PR을 올렸는데 리뷰어의 피트백에 따라 작은 수정사항이 여러 번 발생할 수 있습니다. 이때 Squash Merge를 사용하면 모든 수정사항을 하나의 커밋으로 통합해 깔끔한 히스토리를 유지할 수 있습니다.

3. Rebase Merge

내가 작업한 커밋들을 다른 브랜치의 최신 상태 위로 "재배치"하는 작업입니다.

장점 :

• 브랜치의 커밋 히스토리를 깔끔하게 유지할 수 있습니다.
• Rebase를 사용하면 커밋들이 마치 한 줄로 쭉 나열된 것처럼 보입니다.

단점 :

• 원격 저장소에 올라간 브랜치에 대해 리베이스를 사용하면 다른 개발자의 작업에 영향을 줄 수 있습니다.
• 리베이스 과정에서 충돌이 발생하면 각 커밋마다 충돌을 해결해야 하므로 번거로울 수 있습니다.

적용 상황 :

• 내 작업을 최신 상태로 유지하고 싶을 때:
  예를 들어, main 브랜치에서 분기한 feature/login 브랜치를 작업 중인데 다른 팀원들이 main 브랜치에 새로운 코드를 추가했다면 Rebase를 사용해 feature/login 브랜치를 main 브랜치의 최신 상태 위로 재배치할 수 있습니다.
• PR(Pull Request)을 보내기 전에 히스토리를 정리하고 싶을 때:
  PR을 보내기 전에 Rebase를 사용해 커밋 히스토리를 깔끔하게 정리하면 리뷰어가 코드를 더 쉽게 이해할 수 있습니다.