git rebase와 git merge의 차이점

git에서 두 개의 브랜치를 합치는 명령어 rebase, merge에 대해서 설명하고, 차이점에 대해 정리해둔 문서입니다.

차이점 (1) 병합의 방식 (2) 사용하는 상황

---

(1) 병합의 방식

rebase :

히스토리가 직선형으로 정리되며, 브랜치 간의 작업 병합 흔적이 사라집니다. 이 과정에서 새 커밋 해시를 생성하므로, 히스토리가 변경됩니다.

 

---

         D -- E(experiment)

        /

A -- B -- C(main)

$git chekcout experiment
$git rebase main

 

A  --  B  --  C (main)  --  D'  --  E' (experiment)

---

=> B 브랜치를 베이스로 새로운 가지를 만들었던 사실이 사라지고, main 브랜치 커밋 위로 experiment 브랜치의 커밋들이 쌓입니다. 커밋해시가 변경되기 때문에  D', E'로 표현합니다.

 

 

 

---

merge :

두 브랜치를 병합하며, 히스토리를 보존합니다. 두 브랜치의 커밋을 합쳐 새로운 커밋을 생성합니다.

---

 

         D -- E(experiment)

        /

A -- B -- C(main)

 

$git checkout main
$git merge experiment

 

         D -- E(experiment)

        /         ＼

A -- B -- C -- F (main)

---

=> main과 experiment 브랜치의 커밋 내용이 병합돼 새로운 F라는 커밋이 생성되고, main 브랜치는 병합된 F 커밋의 상태로 존재합니다.

 

 

 

---

 

 

(2) 사용하는 상황

일반적으로 커밋 히스토리에 대한 두 가지 관점이 존재합니다.

 

- opinion1 : Repository’s commit history is "story of how your project was made"
- opinion2 : Repository’s commit history is "record of what actually happened"

 

프로젝트가 어떻게 만들어졌는가에 대한 이야기 VS 실제로 일어난 일에 대한 기록

 

이 관점에서는 커밋 히스토리를 깔끔하고 논리적으로 정리하려고 합니다. 주로 rebase를 사용하여 불필요한 커밋을 제거하거나, 작업 과정을 재구성합니다.

이 관점에서는 커밋 히스토리가 작업의 모든 과정을 충실히 반영해야 한다고 봅니다. 주로 merge를 사용하여 작업 내용을 있는 그대로 보존합니다.

 

rebase는 히스토리를 정리할 때 유용하지만, 커밋이 삭제되거나 변경될 수 있기 때문에 협업 환경에서는 주의해서 사용해야 합니다. 특히, 공개된 브랜치에서의 rebase는 이전 작업이 없어질 위험이 있으므로 권장되지 않습니다.

---

참고 : Git 브랜칭 - 리베이스 (https://git-scm.com/book/en/v2/Git-Branching-Rebasing)