[GIT] Merge vs Rebase 차이

GIT을 프로젝트를 하며 다들 자주 사용하시는데,

혹시 브랜치를 병합할 때, Merge와 Rebase을 사용해본 경험이 있으신가요⁉️

 

저는 주로 

Rebase	fork해온 프로젝트를 upstream에 맞게 동기화하고 싶을 때 사용했는데요. 정보를 fetch upstream을 통해 가져오고 rebase을 통해서 병합을 했었어요.
Merge	얘는 upstream이 없고 origin만 있는 상태에서 Git을 관리할 때 사용했었던 방법이에요.

 

사용하면서 어떤 상황에 사용하는지 형태만 보고 사용했었지, '왜 이걸 사용하지'는 생각을 해보지 않았던 것 같아요.

그래서 이번 기회에 동작 원리를 알아보고 정리해보려고해요~~

 

기회가 된다면 다음 GIT 포스팅은 오픈소스를 관리하는 방식인 fokr한 저장소를 관리하는 방법을 알아볼게요..‼️

 

그렇다면 이제 Rebase vs Merge의 동작원리에 대해 같이 알아보고 플로우를 중심으로 정리를 해볼게요.

 

시작하기 앞서 각 명령어를 실행하기 전, 다음과 같은 commit 이력을 가졌다고 생각하고 설명을 해볼게요.

 

초록색 - master branch

노란색 - sub branch

 

Merge

Merge라는 이름으로만 봤을 때, Branch을 병합해주는 작업인거같죠⁉️

그렇다면 한번 초록색의 master 브랜치에서 노란색의 sub 브랜치를 $git merge로 병합을 실행해볼게요.

master에서 merge을 실행한 결과 master 브랜치의 HEAD에 새롭게 커밋이력이 생성된 것이 확인되죠.

이렇듯, merge는 실행한 브랜치로 병합을 실행하고 새로운 커밋이력을 생성하는 것을 확인할 수 있습니다.

 

물론 이 과정에서 초록색의 master 브랜치와 노란색의 sub 브랜치가 같은 부분을 건드리면 conflict가 발생할 수 있습니다‼️

당황하지 마시고 충돌이 난 부분을 직접 고쳐주고 다시 add -> commit을 실행시켜 주면 됩니다.

 

merge 명령어는 정말 간단하죠⁉️

 

그렇다면 다음으로 Rebase 명령어를 알아볼게요.

 

Rebase

Rebase는 이름으로만 봤을 때, 무슨 의미인 것 같나요??

뭔가 어딘가를 기준으로 새롭게 둥지를 튼다...? 그런 느낌인 것 같죠.

 

네... 맞아요.. 이렇게 말로만하면 무슨 말인지 잘 이해가 되지 않죠.

다시 한 번, 아까 명령어를 실행하기 전 이력을 기준으로 Rebase을 실행해볼게요.

 

아, 이번에는 두 가지의 경우를 그림으로 살펴볼 거에요.

먼저 초록색의 master 브랜치에서 노란색의 sub 브랜치를 $git rebase로 실행해볼게요.

초록색의 master 브랜치에서 노란색의 sub 브랜치을 기준으로 rebase 시켰기 때문에 sub 브랜치를 베이스(Base)로 커밋 이력이 정렬되는 것을 알 수 있죠⁉️

 

 

그렇다면 반대로 노란색의 sub 브랜치에서 초록색의 master 브랜치를 rebase 시키면 플로우가 어떻게 변할까요.

노란색의 sub 브랜치에서 초록색의 master 브랜치을 기준으로 rebase 시켰기 때문에, master 브랜치를 베이스(Base)로 커밋 이력이 정렬되죠⁉️

 

즉, rebase는 어떤 특정 브랜치를 base로 커밋 이력을 재정렬하겠다는 명령어 입니다.

그리고 여기서 주의해서 보셔야하는게 있어요.

 

재정렬된 커밋이력에 (') 가 추가되면서 해쉬 ID가 바뀌는 것을 확인하실 수 있죠.

즉, 여기서 merge와 가장 다른 점이 발견됩니다.

 

재정렬되는 commit 이력이기 때문에, 재정렬되는 commit 이력에는 이전과는 다른 새로운 해쉬 ID가 부여됩니다.

 

만약 master 브랜치에서 다른 브랜치를 기준으로 rebase을 실행하면, master의 커밋이력이 변하겠죠...?

그렇기 때문에, master 브랜치에서 다른 브랜치를 기준으로 rebase을 하는 경우는 피하는게 좋을 것 같습니다.

 

---

 

이러한 rebase는 어떤 상황에서 사용할 수 있을까요?

 

가장 자주 사용되는 경우는 커밋 이력을 깔끔하게 관리하는 경우에 사용할 수 있습니다.

이전에 말했듯이, master 브랜치에서 다른 브랜치를 rebase하는 경우는 피하는게 좋다고 말을 했죠.

 

그렇다면 반대의 경우는 어땠나요?

rebase을 실행하면 다른 브랜치의 커밋 이력 위에서 master 브랜치를 기준으로 다른 브랜치의 커밋이력이 깔끔하게 재정렬이 되었습니다.

 

즉, master 브랜치와는 상관없이 다른 브랜치의 이력 위에서 master 브랜치를 base로 재정렬이 됩니다.

 

한마디로 fast-forward merge가 가능하다는 말이겠죠.

 

 

 

Rebase 사용 간단한 커밋이력 관리법

master 브랜치에서 다른 브랜치로의 rebase는 지양하는 것이 좋다고 했죠.

이를 유의해서 순서대로 설명을 하겠습니다.

 

현재 브랜치는 master, sub가 있다고 가정할게요.

 

1️⃣master로부터 sub 브랜치를 생성하고 작업을 한다.

기존에 협업 방식과 똑같이 master로부터 브랜치를 생성하고 작업을 하시면 됩니다.

 

2️⃣$git checkout sub을 실행한다.

master을 기준으로 rebase을 실행하기 위해 작업단위를 이동합니다.

 

3️⃣$git rebase master을 실행한다.

master을 기준으로 rebase을 실행합니다.
위에 그림에서 보셨던 것과 같이 master을 기준으로 sub 브랜치의 이력들이 정리되겠죠?

 

4️⃣$git checkout master을 실행한다.

여기서 중요합니다. 왜 rebase만 실행했으면 됐지 다시 master로 이동할까요?
바로 현재 작업은 sub 브랜치 위에서의 이력을 정리하기 위한 작업입니다.
master을 기준으로 정렬된 이력을 master에 반영을 해야합니다.

 

5️⃣$git merge sub로 최종 내역을 master 브랜치에 반영한다.

지금까지 작업한 내용을 master 브랜치에 반영하여야 마지막 작업이 완료됩니다.
이렇게하면, sub 브랜치와 master 브랜치의 작업들이 같은 작업 트리로 동기화가 완료됩니다.

 

---

 

오늘은 Rebase vs Merge 명령어의 차이에 대해 자세히 알아봤어요.

 

깔끔한 커밋이력 관리를 위해 rebase 사용에 익숙해져서 사용하면 좋은 이력 관리가 가능할 것 같아요.

그렇다면 GIT 포스팅에서는 rebase을 사용해 fork해 온 프로젝트를 관리하는 방법에 대해 알아볼게요 🙌