[Git] Rebase는 왜 쓰나
kindof
·2022. 4. 13. 21:34
0. 들어가면서
아래와 같은 상황을 보겠습니다.
처음 시작점을 기준으로 Master가 두 번의 Commit을 한 뒤, 'feat' 이라는 브랜치(branch)를 생성했습니다.
그리고 브랜치가 생긴 시점(Base)으로부터 feat 브랜치는 두 번의 commit을 더했고, master 역시 두 번의 커밋을 더 진행했습니다. 이 상황에서 master의 변경 사항을 feat 브랜치에 반영하고 싶습니다.
그러면 아래와 같이 병합(Merge)을 통해 master와 feat의 최신 Commit을 공통의 조상으로 하는 새로운 Commit을 생성할 수 있습니다.
그리고 feat 브랜치는 이제 새로 생성된 Commit의 위치로 이동하게 됩니다. 이를 3-Way Merge라고도 합니다.
한편, 이 상황에서 Rebase를 사용하게 되면 아래와 같이 feat 브랜치의 Commit 히스토리가 사라지고, 새로운 Commit이 아닌 Master 브랜치의 Base를 기준으로 새로운 뿌리가 뻗어나가게 됩니다.
Merge, Rebase의 그림을 비교해보면 두 방식 모두 Commit 내용을 병합하는 목적으로 쓰인다는 것을 알 수 있습니다. 다만 구체적인 동작 방식에서 차이점을 갖게 되는 것인데요.
이 맥락에서, 오늘 이야기 할 Rebase는 위와 같은 Merge의 어떤 단점 혹은 불만족을 해소하기 위해 필요한 개념입니다. 그러면 Merge만을 사용해야 할 때 어떤 문제점이 있는지를 먼저 알아야 할 것 같습니다.
1. Merge의 문제점과 Rebase
Merge 방식의 문제점은 위에서 소개했던 그림을 보면 확인할 수 있습니다. 바로 1) 새로운 Merge Commit이 생긴다는 것, 2) Merge를 한 브랜치의 모든 Commit 기록이 남아있다는 것입니다.
조금 더 구체적으로 이 문제에 대해 들여다보겠습니다.
많은 프로젝트들에서 사용하고 있는 Branch 전략은 Master > Dev > Feature 구조의 브랜치 생성입니다.Master는 실제로 배포용으로 사용되는 브랜치이며, develop 브랜치는 그 하위에서 여러 기능들을 수합하고 테스트하여 Master 브랜치에 전달하기 전 역할을 하는 브랜치입니다. 그리고 여러 개의 feature 브랜치는 프로젝트의 세부 기능들을 구현하는 단위로 역할을 하죠.
위와 같은 전략을 가지고, Merge를 통해 프로젝트를 진행한다고 해보겠습니다.
위 그림은 C1 단계에서 feature 3, 4, 5 브랜치를 생성하고, 각 feature 브랜치에서 기능을 개발한 뒤 develop 브랜치와 Merge하는 상황입니다. 이러한 Commit 기록의 의도는 분명합니다. feature 브랜치에서 작업한 내용들을 develop 브랜치에 반영하는 것이죠.
그러면 위와 같은 Merge 전략 대신에 C3가 M1 자리, C4가 M2 자리, C5가 M3 자리를 대신하는 것은 어떨까요?
실제로 협업을 하는 관점에서는 feature 브랜치에서 develop 브랜치에 병합을 하는 것은 너무나 당연한 과정이고 정작 중요한 것은 각 feature에서 일어난 작업이 무엇인지에 있기 때문입니다. 심지어 더 많은 수의 개발자가 기능을 나누어서 하위 브랜치를 관리하고 하루에 4~5번씩 Commit, Merge를 하게 되면 Git History를 관리하는 데 골치가 아파질 것입니다.
그래서 위와 같은 Merge 전략은 아래와 같은 Rebase 전략으로 대체되는 것이 좋을 수 있습니다.
2. 나가면서
Rebase는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치는 개념입니다. 그리고 이를 통해 Merge보다 Commit 히스토리를 깔끔하게 관리할 수 있죠. 하지만 Rebase에 대해 공부를 해보면서 오늘 설명한 내용은 극히 일부라는 것을 알게 됐습니다.
나중에 좀 더 능숙하게 rebase를 다루게 될 때 더 많은 내용을 정리해보겠습니다.
3. Reference
https://meetup.toast.com/posts/122
'Git' 카테고리의 다른 글
Github PR(Pull Request) 생성 전 생각해보면 좋을 것들 (1) | 2024.01.14 |
---|---|
작업 중인 브랜치에 다른 히스토리를 반영해야 할 때: Merge? Rebase? (0) | 2022.10.31 |