[GIT 좀 더 이해하기] 3. merge 와 rebase 차이

 

rebase

 rebase를 하는 것이 merge 보다 히스토리를 깔끔하게 한다고 합니다. 보통 이 정도의 차이로만 인식하고, rebase를 merge의 대체제로 쓰신다던가 하는 불상사가 일어나기도 하는데요. 이번 포스팅에서는 둘의 차이점을 알고, 용도에 맞게 어떻게 쓰면 좋을지 알아봅니다.

 

이번 포스팅에서 다루지 않는 것

• merge의 개념
• rebase의 개념

위 2가지는 여러 레퍼런스가 있으니, 그곳에서 먼저 참고하시길 바랍니다. 

https://backlog.com/git-tutorial/kr/stepup/stepup2_4.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

---

시나리오 1.  feature 브랜치 작업 중 base 브랜치의 수정 발생

 

develop 브랜치가 존재한다고 가정하고, 레이아웃 수정작업을 진행해야 합니다. 일반적으로 아래와 같이 작업을 진행하겠죠.

 

브랜치 작업계획

1. feature 브랜치 생성 (feat/layout)
2. feature 브랜치에서 작업
3. 작업 완료 후 develop 브랜치로 병합

 

작업 계획대로 진행해 보겠습니다. git 명령어로 작업하며, GUI는 SourceTree를 사용했습니다.

## feat/layout 브랜치 생성
git checkout -b feat/layout

분기해서 작업 시작

그리고 feature 브랜치에서 열심히 작업을 진행하고 있었습니다. 그런데 develop 브랜치에 긴급 커밋이 올라왔습니다. 아래 그림을 볼까요

 

devlop의 커밋이 추가되었다

아직 feature 브랜치의 작업이 끝나지 않았습니다. 그러나 develop의 긴급 커밋 내용이 설정파일 오류 수정이라 feature 브랜치에도 커밋이 반영되어야 하는 상황이면 어떡할까요. 먼저 이런 상황을 non fast-forward 상황이라 하고, 이때 병합을 위해선 2가지를 할 수 있습니다.

 

non fast-forward 조건에서의 병합 방법

• merge
• rebase

 

방법 1.  merge

보통 merge를 하시겠죠. 이렇게요

git merge develop

그리고 작업을 이어나가면 됩니다.

 

작업이 끝나면 merge 하면 됩니다

방법 2. rebase

그런데 rebase 하는 방법도 있습니다. 먼저 실행결과를 보셔야 이해가 가실 텐데요.

 

*  본인은 git reset -hard "돌아가고픈 commit number"로 merge를 취소한 뒤 rebase를 진행함

git rebase develop

 

feature 브랜치의 참조 커밋이 develop의 긴급 수정 커밋을 바라보게 되었습니다. 줄기가 하나로 합쳐졌습니다.

 

이제 작업을 이어나갑니다. 

 

작업이 완료되었다면 develop을 fast-forward 하면 됩니다.

## git merge 시 기본옵션은 fast-forward
git merge feat/layout

fast-forward merge

이력관리를 위해 non fast-forward를 할 수도 있겠죠

git merge --no-ff feat/layout

non ff merge

 

최종 결과만 비교해 보겠습니다. merge와 reabe의 작업내역입니다.

 

merge vs rebase

 최종적으로 fast-forward를 사용한 rebase가 깔끔해 보이긴 하나, 그렇게 큰 장점인지는 모르겠습니다. 그러나 이건 줄기가 2개라 이렇습니다. 세 줄기가 탄생하는 히스토리에선 어떨까요

---

시나리오 2. 협업 인원이 많을 때

주문페이지를 수정해야 하는데 백엔드, 프런트엔드 총 2명이 협업한다고 가정해 보겠습니다.

feature 브랜치를 생성해 이전과 마찬가지로 작업을 시작합니다. 그리고 중간에 프런트엔드 개발자가 투입하여 작업합니다.

줄기가 3개가 되었네요.  그리고 레이아웃 작업은 끝났다고 합니다. 따라서 feat/order_ui 브랜치는 병합해야 하는데요.

이때 rebase로 진행해서 최종 develop merge까지 가보겠습니다.

 

 프런트엔드 개발자 때문에 생겼던 줄기가 사라졌습니다.  줄기가 많은 히스토리에서는 변경 이력 관리를 보기 쉽게 관리하기 위해 rebase를 사용하곤 합니다.

---

 

rebase와 merge 중 무엇을 써야 할까 (주관적)

 이제 둘 중 무엇을 쓸지 고민해야 합니다. 정답은 없으되 일반적으로 merge를 쓰는 것을 추천드립니다.  rebase는 줄기가 합쳐지기 때문에 당시의 히스토리를 일부 생략해서 보여줍니다. 위 시나리오 2에서 봤듯 프런트엔드 개발자가 작업했던 줄기는 사라지고 마치 하나의 브랜치에서 백엔드 개발자와 프런트 개발자가 작업한 것처럼 보여주니까요. 

 

 merge는 변경이력을 모두 보존하여 줄기를 어지럽히지만, 적어도 줄기를 없애지는 않습니다. rebase는 줄기를 합쳐 자잘한 줄기들을 제거해 히스토리 파악을 더 용이하게 합니다. 정확한 이력을 남겨야 할 때는 merge가 좋은데 사실 이력을 정확히 남긴다는 건 형상 관리의 철학이기도 해서 rebase와 충돌하는 부분이기도 합니다. 

 

 로컬 브랜치에서만 작업하면서 임시로 생성한 브랜치들을 제거하기 위한 다면 rebase를 적극 사용하시면 좋을 것 같습니다. 굳이 로컬에서까지 나만 보기 위해서 작업이력을 산재시켜 놓을 필요는 없으니까요

---

참고

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

Git - Rebase 하기