본문 바로가기
Infrastructure/Git

[Git]Merge vs Rebase Rebase를 중점으로 봐보자

by 곰민 2023. 2. 25.

git base ci/cd tool 들은 커밋 또는 브랜치의 변경 사항을 다른 브랜치나 커밋에 반영할 수 있도록 지원하는데 이를 보통 Merge와 Rebase라고 한다.
여기서 한가지 의문점이 생길 수 있는데 왜 굳이 Merge와 Rebase 2개의 방법을 제공하는 걸까? Merge와 Rebase를 Rebase를 중점으로 알아보도록 하자.

 

출처 :https://giphy.com/gifs/git-merge-cFkiFMDg3iFoI

하지만 짤은 Conflict 나는 개판 Merge 짤이다 😱😱😱😱😱😱😱😱😱😱

 

Merge


전제

main 브랜치로 부터 Feature 브랜치를 따고 3가지 커밋이 이루어져 있다

main 브랜치는 Feature 브랜치가 따진 이후 2번의 커밋이 이루어져 있는 상황이다.

 

git checkout feature
git merge maian
//or
git merge feature main

 

git merge
출처 :https://www.atlassian.com/git/tutorials/merging-vs-rebasing

첫 번째로 Merge이다.

Main 브랜치와 Feature 브랜치 간 변경 내용을 합쳐서 Merge Commit으로 Feature 브랜치에 커밋됩니다.

Merge는 non-destructive 즉 기존 브랜치가 없어지지 않으며 추가적인 계발을 지속해서 해나갈 수 있습니다.

 

Rebase


git checkout feature
git rebase maian

 

git rebase
출처 :https://www.atlassian.com/git/tutorials/merging-vs-rebasing

 

 

Rebase 즉 base로 하는 지점을 다시 잡겠다는 의미입니다.

 

1. 원하는 브랜치로 checkout 하고

2. git rebase 명령을 실행하여 Rebase 할 브랜치를 지정합니다.

3. Checkout 한 브랜치의 변경 내용을 Rebase 브랜치의 끝 부분에 통합하는 새 커밋 집합이 만들어집니다.

4. Rebase가 완료되면은 두 브랜치의 변경 내용을 통합한 단일 브랜치를 갖게 됩니다.

 

위의 예시로 본다면 Rebase의 경우 분기가 일어난 이후 3번 커밋한 만큼의 Feature 형상이 Main 브랜치의 최신 형상을 base로 맨 앞으로 놓이게 됩니다.

Merge 와는 다르게 각각의 브랜치가 여전히 존재하지 않고 하나로 통합되며 브랜치 분기를 원한다면 Rebase 된 현재 브랜치에서 추가적인 Feature 브랜치나 다른 브랜치를 분기해서 파야 합니다.

 

장점

1. 불필요한 Merge 커밋이 없습니다.

2. 프로젝트 히스토리가 완전히 선형으로 변형되어 Feature 브랜치를 따로 추적하고 확인하며 기능확인을 하지 않고 처음부터 끝까지 선형적으로 프로젝트 히스토리를 따라갈 수 있습니다.

 

 

Public 브랜치에서의 Rebase


git checkout main
git rebase feature

git rebase
출처 :https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Main 브랜치가 Master 브랜치이고 다수의 개발자들과 협력 중이던 브랜치라고 생각해 봅시다.

어느 순간 Main 브랜치에서 Feature 브랜치의 특정 지점으로 Rebase를 진행하게 된다면

어김없이 해당 Feature 브랜치의 변경사항에 가장 최근 지점으로 Main 브랜치의 커밋사항들을 이동시킵니다.

문제는 이런 이동이 Rebase를 실행한 저의 Repository에만 발생한다는 것입니다.

즉 다른 개발자들의 Main 브랜치는 Rebase 하기 전 형상을 유지하고 있습니다.

 

Master 브랜치를 공유하며 사용하고 있는데 두 Master 브랜치 간 형상이 틀어지게 됩니다.

이 두 브랜치간 형상을 다시 맞추기 위해서는 또 다른 Merge 작업이 필요하게 됩니다.

 

위와 같은 문제 때문에 public 브랜치 즉 다른 개발자들과 협업하고 있는 public 한 브랜치에 Checkout 한 뒤
특정 브랜치로 절대 Rebase 하지 않기를 강력하게 권장합니다.

 

유용하게 사용할 수 있는 상황


git flow를 활용하는 상황에서 기능 개발에 있어 여러 가지 feature 브랜치를 따서 작업할 수 있습니다.
그런데 때때로, main 브랜치에 feature 브랜치와 관련 없는 변경사항이 반영될 수 있습니다.
이런 경우, feature 브랜치에서 main 브랜치를 rebase합니다.

feature 브랜치에서는 개발 중인 코드를 비공개로 유지하고, main 브랜치에는 불필요한 merge 커밋을 없애면서도 conflict가 발생할 가능성을 줄일 수 있습니다.
이를 통해 history 관리도 보다 편리하게 할 수 있습니다. 따라서, 해당 상황에서는 안전하게 rebase를 사용할 수 있다고 생각합니다.

 

참조


https://www.atlassian.com/git/tutorials/merging-vs-rebasing

https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge

https://medium.com/@harishlyadav/when-to-use-git-rebase-explained-3c8192cba5c7

반응형

댓글