[Git] Rebase와 Merge의 차이점

1. Rebase 란?

• 브랜치와 브랜치를 병합하는 명령어 중 하나다.
• Merge와는 다르게 히스토리가 합쳐져서 한 줄(선형)로 남는다.
  • 단, 히스토리가 변경된다는 점을 꼭 기억해야 한다.
• Rebase는 기존 커밋들이 단순히 옮겨지는 것이 아니라, 새로운 커밋들이 복사되어 기존 브랜치 위에 이어붙여진다.
  • 따라서 기존 커밋과 겉보기 내용이 같아도 Git에서는 다른 커밋(SHA-1 해시가 달라 새로운 커밋)으로 인식한다.
• Merge가 보통 main 브랜치에서 실행되지만, Rebase는 작업하고 있는 자신의 브랜치에서 "기준 브랜치(main 등)"을 지정하여 실행한다.
  • 예: 작업 브랜치에서 git rebase main 명령어를 사용한다.
• 결과적으로 Rebase를 하면 히스토리가 선형으로 정리되어, 히스토리가 깔끔해지고 이해하기 쉬워진다.
• 다만, 이미 원격 저장소에 공개한 커밋을 Rebase로 변경하면 협업자들 사이에서 히스토리가 꼬여 충돌, 푸시 거절 같은 문제가 발생할 수 있으니 주의해야 한다.

아래 이미지들을 같이 보자.

※ 필자는 화살표가 왼쪽으로 되어있어 헷갈렸는데 시간순서를 오른쪽으로 보면 될 것 같다.

이미지 1

위 이미지1을 보자.

master브랜치와 experiment브랜치는 C2커밋에서 분기되어 각각 독립적인 브랜치로 나누어진 상태다.

즉, 누군가 master 브랜치에서 새 브랜치를 만들어 작업을 시작한 상황이라고 이해하면 된다.

⚠️

현재 기준으로 master브랜치보단 최근 Git 흐름에 맞춰 main 브랜치로 보는 것이 적절하며, experiment 브랜치는 작업자 혹은 개발자가 진행 중인 브랜치 정도로 생각하면 됩니다.

이미지 2

이미지1의 상태에서 experiment 브랜치를 Rebase하면, 기존 experiment 브랜치는 삭제되고, 그 브랜치의 커밋인 C4가 master 브랜치 위로 복제되어 합쳐지는 것을 확인할 수 있습니다.

⚠️

여기서 C4'는 단순히 이름이 바뀐 것이 아니라, 내용은 같지만 SHA-1 해시가 다른 완전히 새로운 커밋입니다. 즉, Git 입장에서는 전혀 다른 커밋으로 취급됩니다.

또한 Merge와 달리, Rebase는 작업 브랜치(experiment)에서 명령을 실행한다는 점이 특징입니다.

$ git switch experiment

$ git rebase master

이미지3

결국 이미지1과 이미지2의 과정을 통해 History가 한 줄로 합쳐지게 되는데, 이때 기억해야할 점은 기존 커밋이 사라지고 내용이 같은 커밋 복사본이 History에 남는다는 것이다.

기존커밋과 복사 커밋의 차이로 해쉬코드가 다르기에 Git에서는 내용은 같을 지언정 아예 다른 커밋으로 간주한다.

2. Rebase 주의점

rebase의 위험성 (Git 공홈 본문의 내용)

위 이미지는 Git홈페이지 공홈에 적인 내용이다.

1. 이미 공개 저장소에 Push 한 커밋에 Rebase 하지마라.

2. 1을 지키지 않을시 욕을 먹는다.

위에서도 몇 번 언급 했지만 Rebase의 경우 History를 변경하게 된다.

이때 기존 커밋은 삭제되고 새로운 복사본으로 커밋의 History가 변경된다.

그런데 다른 작업자들이 어떠한 커밋 이력을 바탕으로 작업중인데 내가 그 커밋이력을 협의 없이 변경하고

다른 작업자들이 push할 때 코드가 꼬인다?

상상하기 싫다.🚨

rebase는 원격 저장소에 올리기 전, 나의 로컬에서만 사용하기로 하자.

---

3. Merge 란?

• Merge를 실행하면, 두 브랜치의 공통 조상을 기준으로 새롭게 합쳐진 작업 내역을 포함하는 새로운 병합 커밋(merge commit)이 생성된다.
• 이로 인해 두 브랜치의 변경 사항이 모두 반영되면서, 히스토리에는 병합 사실이 명확히 남는다.
• Merge는 보통 메인 브랜치(main 등)에서 실행하여 작업 브랜치의 변화를 메인에 통합할 때 사용된다.
• 병합 커밋이 생기기 때문에 히스토리가 복잡해질 수 있지만, 브랜치의 전체 이력을 모두 유지하고 있어서 협업 시 안전하고 추적이 용이하다.
• 충돌이 발생하면 한 번에 해결하며, 작업 내용 손실 위험이 비교적 적다.

아래 이미지들을 같이 보자.

※ 필자는 화살표가 왼쪽으로 되어있어 헷갈렸는데 시간순서를 오른쪽으로 보면 될 것 같다.

이미지 1

master브랜치와 iss53브랜치는 C2라는 공통 커밋에서 분기되어 진 커밋들이다.

즉, C2커밋에서 분기하여 2개의 작업이 공통으로 되고 있다고 생각하자.

⚠️

현재 기준으로 master브랜치보단 최근 Git 흐름에 맞춰 main 브랜치로 보는 것이 적절하며, iss53 브랜치는 작업자 혹은 개발자가 진행 중인 브랜치 정도로 생각하면 됩니다.

이미지 2

이미지 2는 mater브랜치에서 merge를 완료한 커밋 기록이다.

Rebase와 다른점은 커밋 이력이 한 줄(선형)이 아니라 브랜치끼리 합쳐진 모양이다.

앞서 설명한 Rebase대로 했다면 C3, C5가 사라지고 C3`, C5`라는 복제 커밋이 생기고 C4커밋 라인과 합쳐서 한 줄로 표기 되었을 것이다.

또한 Rebase와 다른 점은 Merge는 브랜치를 합하는 브랜치에 가서 행동해야한다.

$ git switch main
$ git merge iss53

---

4. Merge와 Rebase의 차이

	커밋 이력 (History)	장점	단점
Rebase	커밋 이력이 사라지고 한 줄로 남는다.	히스토리가 깔끔해진다.	협업시 충돌 우려가 있으며 커밋이력을 추적하기 힘들다.
Merge	모든 커밋 이력이 남는다.	모든 커밋 이력을 추적 가능하다.	히스토리가 지나치게 복잡해질 가능성이 크다.

 

 

😊 로컬에서 작업할 때는 적절하게 Rebase를 활용하여 커밋이력을 깔끔하게 정리하고, Push 이후엔 건들지 말자.

 

※ 모든 이미지의 출처는 Git 공홈에 있습니다. https://git-scm.com/book/ko/v2