Git 협업 브랜치 전략: Merge, Rebase, Squash 언제 써야 할까?

1. Git merge 방법

1️⃣ Merge

• 일반적으로 많이 사용하는 merge 방법, 커밋 이력을 모두 남길 때 사용
• 두 브랜치의 히스토리를 그대로 보존하면서 병합하는 방식
• merge 전용 커밋이 하나 생성

main ── A ── B ──────── M
         \              /
feature    C ── D ────

2️⃣ Squash and Merge

• feature 브랜치의 여러 커밋을 하나의 커밋으로 압축해서 병합

main ── A ── B ── S
(S = feature 브랜치 커밋들을 합친 하나의 커밋)

3️⃣ Rebase and Merge

• 브랜치의 기준점을 옮겨서, 마치 한 줄로 작업한 것처럼 커밋을 다시 쌓는 방식
• ⚠️ 기존 커밋을 수정하는 것이 아니라 새 커밋을 다시 만드는 히스토리 재작성이다.

(rebase 전)
main ── A ── B
         \
feature    C ── D
 
(rebase 후)
main ── A ── B ── C' ── D'

2. 왜 협업에서 rebase를 조심해야 할까?

Git을 조금이라도 써봤다면, “rebase는 협업에서 쓰면 안 된다” “이미 push한 브랜치에 rebase하면 사고 난다” 라는 말을 한 번쯤은 들어봤을 것이다.

이 말은 막연한 금기나 경험담이 아니라, rebase가 Git 히스토리를 다루는 방식 자체에서 비롯된 경고다.
왜 이런 이야기가 나왔는지를 이해하려면, 먼저 rebase가 실제로 어떤 일을 하는지부터 짚어볼 필요가 있다.

3. 그렇다면 git pull --rebase는 예외일까?

앞에서 rebase가 협업에서 위험하다고 설명했다면, 여기서 자연스럽게 이런 의문이 든다.

"그럼 git pull --rebase는 써도 될까? 이것도 결국 rebase 인데 괜찮을까?"

➡️ 결론부터 말하면, git pull --rebase는 조건부로 안전한 예외에 가깝다.

git fetch
git merge

🤔 왜 이건 괜찮을까?

핵심 차이는 누구의 커밋을 rebase 하느냐다.

git pull --rebase가 안전한 이유는 다음 조건을 만족하기 때문이다.

• rebase 대상은 내 로컬 커밋뿐
• 아직 원격에 공유되지 않은 커밋
• 원격 브랜치의 히스토리는 절대 수정하지 않음
• 강제 push가 필요 없음

➡️ 즉, 다른 사람이 보고 있는 히스토리를 건드리지 않는다.

4. 우리 팀에서는 어떤 merge 전략을 선택해야 할까?

이 질문에 대한 정답은 "무조건 이것이 맞다"가 아니라,
우리 팀의 브랜치 전략과 협업 방식에 맞는 기본 조합을 정하는 것이다.

각 브랜치의 역할이 다르기 때문에, merge 전략도 달라지는 것이 자연스럽다.

5. 결국 중요한 건 “도구”보다 “합의”

이 글을 정리하면서 느낀 점은, Git을 잘 쓰는 팀은 어디서 어떤 전략을 쓸지 합의가 된 팀이라는 것이다.

• 어떤 브랜치에서 rebase를 허용하는지
• squash를 기본으로 할지
• main 히스토리를 어떻게 유지할지

이런 것들이 정리되어 있지 않으면, 아무리 좋은 전략도 결국 사람마다 다르게 쓰이게 된다.