[Git] Rebase

Git rebase 란

일련의 커밋을 새 기본 커밋으로 이동하거나 결합하는 프로세스로 브랜치를 병합하는 전략 중 하나이다.

말 그대로 브랜치 히스토리들의 베이스를 변경하는 방법인데 여기서 베이스란 무엇일까?

Git에서 베이스란 나의 브랜치를 딴 시점의 Master Base를 의미하며, Master Base란 Master Branch의 HEAD를 가르킨다.

결국 브랜치가 분기되기 시작하는 시점의 Master Branch의 HEAD를 베이스라 한다. 

아래 이미지에서 ddf19c2 가 베이스를 의미한다고 보면 되겠다.

 

Git rebase는 어떻게 동작할까?

위와 같은 상황을 가정하여 설명하자

현재 위치는 feature 브랜치로 head는 feature를 가리키고 있으며, 현재 베이스는 b인 상태이며 rebase를 진행해보자.

git rebase master

rebase를 하게 되면 베이스인 b로부터 feature까지의 변경된 커밋들에 대해 순서대로 임시저장소에 Patch로 저장한다.

베이스는 b -> m2로 베이스가 변경되며 임시로 저장한 Patch 정보를 가져와 베이스에 병합을 하게 된다. 이때 feature의 커밋은 2개인 상황으로 첫번째 f1 커밋을 병합하고 다시 한번 Patch 정보를 가져와 두번째 f2 커밋을 병합하는 식으로 나아간다.

rebase가 마무리되면 feature와 master가 합쳐져 Merge 할때의 병렬 모양의 트리구조가 아닌 선형 모양의 트리구조를 갖게 되며 마치 master에서 작업을 하고 푸시한것과 같은 히스토리를 확인 할 수 있게 된다.

Rebase 노드 트리구조

Merge 노드 트리구조

 

Git rebase를 왜 사용하는가?

장점

Commit history를 깔끔하게 관리하기 위해 사용한다. rebase를 사용하여 커밋을 편집할 수 있기 때문이다.

Merge Commit이 생성되지 않고, 직관적인 History로 프로젝트를 관리 할 수 있다.

규모가 큰 프로젝트의 경우 직관적인 History는 버그 픽스, 유지 보수 측면에서 더 효율적이라 할 수 있다.

단점

Merge Commit이 생성되지 않아 어느 시점에 브랜치가 머지됬는지 알 수 없어 tag 기능을 활용하여 어느 시점에 머지 되었는지 명시해주는것이 좋다.

Commit이 Merge 되지 않고, 하나하나 씩 올라간다는 점이다. 따라서, 각각의 commit의 conflict을 수정하여 해결 해 주어야 한다.

Merge와 달리 각 커밋 하나하나 모두 충돌을 해결해주어야 한다.

 

Rebase 와 Squash 의 차이점

rebase는 브랜치를 병합하는 방법이며 squash는 커밋을 병합하는 방법이다.

rebase는 Git 명령어이다. Squash는 기능의 일부일뿐 명령어는 아니다.

 

Rebase 와 Merge의 차이점

rebase는 기록(commit)을 변경하며, merge는 기록을 있는 그대로 사용한다.

rebase는 직렬 구조 merge는 병렬 구조를 갖는다.

rebase는 merge commit을 남기지 않는다.

 

주의점 

"Do not rebase commits that exist outside your repository and that people may have based work on."
"다른 동료가 작업 중인 외부에 공개 된 저장소 브랜치를 대상으로 리베이스하면 안됩니다."

rebase는 강제로 푸시해야하는 경우가 있다.

브랜치를 rebase 한후 중앙 서버로 푸시할때 에러가 발생하는데 이유는 origin 서버에 있는 내용과 현재 로컬에 있는 내용의 머지 베이스가 다르기 때문이다.

그렇기에 force push를 해야하는 경우가 발생하는데 force push는 나.의.브.랜.치 에서만 진행해야 한다. master에서 진행하는 경우, 다른 사람들의 commit history 바꾸어 버리게 되기 때문에 지옥을 경험할 수 있다.

실제 많은 기업에서는 이를 방지하기 위해, master force push를 막아 놓기도 한다.

따라서 현재 브랜치가 혼자 작업하는 브랜치가 아니라면 리베이스를 하지 말고! 작업이 완료 된 후 master에 merge 하기 전에만 리베이스를 하도록 하자.

 

Rebase VS Merge

대부분 Merge를 사용하는 사람이 많으며 Squash and merge를 통해 충분히 커밋 히스토리를 관리할 수 있다고 한다.

병합 전략에 대해서 정답은 없으며 회사 및 프로젝트 성격에 맞는 병합 전략을 사용하는 것이 좋다.

정답은 없다.

좋은 참고자료

velog.io/@godori/Git-Rebase

brunch.co.kr/@anonymdevoo/7

tech.10000lab.xyz/git/git-rebase-workflow.html

readystory.tistory.com/151

www.atlassian.com/git/tutorials/rewriting-history/git-rebase

levelup.gitconnected.com/how-to-squash-git-commits-9a095c1bc1fc

velog.io/@rosewwross/git-rebase

 

velog.io/@godori/Git-Rebase

🎢 Git Rebase 활용하기

brunch.co.kr/@anonymdevoo/7

4. Merge 와 Rebase의 차이점

tech.10000lab.xyz/git/git-rebase-workflow.html

깃(Git) 리베이스 사용하기 - 스타트업 엔지니어링

readystory.tistory.com/151

Git Rebase 제대로 알고 쓰기 (feat. cherry-pick)

www.atlassian.com/git/tutorials/rewriting-history/git-rebase

git rebase | Atlassian Git Tutorial

levelup.gitconnected.com/how-to-squash-git-commits-9a095c1bc1fc

How to squash git commits

velog.io/@rosewwross/git-rebase

(git) git rebase