두 브랜치의 변경을 합칠 때 merge와 rebase는 이력을 어떻게 다르게 만들며, 공유 브랜치에서는 무엇을 조심해야 하나요?

merge는 두 브랜치의 기존 커밋을 보존하고 필요하면 두 부모를 가진 merge 커밋을 추가해 분기를 합칩니다. rebase는 한 브랜치의 커밋을 다른 기준점 위에 새 커밋으로 다시 만들어 직선에 가까운 이력을 만듭니다. 내용상 같은 변경을 합칠 수 있어도 커밋 ID와 조상 관계가 달라지므로, 둘은 단순히 보기 좋은 이력과 나쁜 이력의 차이가 아닙니다.

개인 작업 브랜치가 main에서 오래 갈라졌다면 rebase로 최신 기준 위에 다시 올린 뒤 테스트하고 fast-forward로 합치는 방식을 선택할 수 있습니다. 충돌을 커밋 단위로 해결하며 각 커밋의 의미를 정리하기 쉽다는 장점이 있지만, rebase 중에는 같은 변경을 새로 재생성하므로 결과를 반드시 검토해야 합니다. 이미 여러 사람이 기준으로 가져간 브랜치의 커밋을 rebase하고 강제 push하면 그들의 조상 관계가 사라져 pull과 복구가 어려워집니다.

공유 브랜치나 공개 이력은 merge 또는 별도의 통합 커밋으로 보존하고, 개인 브랜치처럼 아직 다른 사람이 기준으로 삼지 않은 이력만 rebase하겠습니다. 강제 push가 필요하다면 일반 --force보다 원격의 새 변경을 덮어쓰지 않는 --force-with-lease를 사용하더라도 정책과 리뷰를 먼저 확인해야 합니다. 어떤 방식을 쓰든 충돌 해결 뒤 테스트와 diff를 확인하고, 이력 재작성 여부와 원격 보호 규칙을 팀에 맞춰 명시하는 것이 핵심입니다.

커밋의 사실과 파일 결과를 구분합니다

merge는 기존 두 계통과 부모 관계를 보존해 통합 지점을 남기고, rebase는 커밋을 새 부모 위에 다시 만들어 ID를 바꿉니다. 따라서 rebase 후 파일 내용이 같아 보인다고 이력이 같은 것은 아닙니다. 충돌 해결 중 양쪽 변경을 잘못 버릴 수 있으므로 원래 브랜치의 변경 목록, 최종 diff, 테스트를 다시 확인합니다. 개인 브랜치처럼 아직 공유되지 않은 이력은 rebase로 최신 기준에 맞추기 쉽지만, 이미 다른 사람이 가져간 브랜치는 그대로 보존하는 편이 안전합니다.

공유 이력을 보호합니다

공유 브랜치를 강제 push하면 동료가 가진 조상과 pull 기준이 사라집니다. --force-with-lease는 내가 본 원격 이후 변경을 덮지 않게 할 뿐, 강제 재작성의 협업 비용을 없애지 않습니다. 보호 브랜치 정책과 리뷰를 우선하고, 선형성이 필요하면 squash merge가 개별 커밋의 추적·부분 복구를 줄이는 비용까지 합의합니다. 잘못 rebase했을 때 reflog로 복구할 수 있어도 복구 절차를 안전장치로만 보고, 통합 전 백업 참조와 중단 지점을 남기겠습니다.

구체적인 경계 사례

main이 A-B로 진행되고 기능 브랜치가 A-C-D라면 merge는 B와 D를 부모로 갖는 M을 만들 수 있고, rebase는 B-C'-D'처럼 C와 D의 변경을 새 부모 위에 적용합니다. 부모가 달라지므로 내용이 같아도 ID는 달라집니다. main이 아직 A라면 기능 브랜치로 fast-forward할 수 있어 merge가 항상 별도 커밋을 만든다는 설명도 맞지 않습니다.

충돌 해결 뒤에는 단순 빌드 외에 원래 의도한 변경 집합과 새 변경 집합을 비교합니다. rebase에서는 range-diff가 커밋별 변화 검토에 도움이 되고, merge에서는 통합 부모와 최종 결과를 함께 봅니다. 이미 공개한 변경을 취소하려면 이력 삭제보다 revert로 새로운 역변경을 남길 수 있지만, 데이터 마이그레이션이나 외부 효과는 Git 파일 되돌리기만으로 복구되지 않습니다.