[GIT] Merge와 Rebase의 차이 및 선택 기준

이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 Merge와 Rebase의 차이 및 선택 기준에 대하여 상세히 알아보겠습니다.

1. 병합 방식의 근본적인 차이

두 명령어 모두 코드를 합친다는 목적은 동일하지만, 기록을 남기는 철학이 다릅니다.

• Merge (병합): 두 갈래의 역사를 있는 그대로 보존합니다. 어디서 분기되었고 언제 합쳐졌는지(Merge Commit)에 대한 족적이 남습니다. 하지만 수십 개의 기능 브랜치가 동시에 병합될 경우, 로그 그래프가 거미줄처럼 매우 복잡해지는 단점이 있습니다.
• Rebase (재배치): 커밋들을 뜯어내어 한 줄로 다시 이어 붙입니다. 병합 커밋이 발생하지 않으며, 그래프가 마치 한 사람이 순차적으로 개발한 것처럼 일직선으로 매우 깔끔해집니다. 단점은 실제 커밋이 발생한 본래의 맥락과 시간 순서가 왜곡된다는 점입니다.

2. 실무에서의 적용 기준

어떤 방식을 사용할지는 전적으로 팀 내의 컨벤션(Convention)에 달렸습니다.

히스토리의 완전한 보존을 중시하는 오픈 소스 프로젝트나 보수적인 기업은 Merge를 선호합니다. 반면, 코드 리뷰의 가독성과 히스토리의 깔끔함을 중시하는 모던 IT 기업에서는 Rebase와 Squash(커밋 뭉치기)를 혼합하여 사용하는 경우가 많습니다.

권장 접근 방식: 개인 로컬 브랜치에서 작업하는 동안에만 메인 브랜치의 최신 코드를 Rebase로 가져오며 히스토리를 정리하고, 최종적으로 원격 저장소에 기능을 반영할 때는 Pull Request를 통해 Merge(또는 Squash and Merge) 방식으로 안전하게 기록을 남기는 것이 가장 널리 쓰이는 전략입니다.

---

지금까지 Merge와 Rebase의 차이 및 선택 기준의 개념과 구체적인 활용 방안에 대해 살펴보았습니다. 이어지는 다음 포스팅에서 관련 심화 주제를 지속적으로 다루어보겠습니다.