Git rebase vs. merge 차이

브랜치를 합치는 방법은 두 가지가 있는데 rebase와 merge의 동작 흐름과 차이에 대해서 알아보자. 알고 있는 개념이긴 하지만 이번 기회에 헷갈리는 부분들을 명확히 하고자 정리한다. 이제 헷갈려서 자꾸 구글링에 시간 쓰는 일이 없기를 🙏

아래 그림은 master 브랜치의 M2 커밋에서 feature 브랜치를 따서 F1, F2 커밋을 한 흐름이다.

git commit history master와 feature 브랜치 커밋 히스토리

위와 같은 상황에서, 협업하는 동료가 master 브랜치에 새로운 작업 사항 M3 커밋을 푸쉬했다고 가정해보자. 만약 feature 브랜치에서 master의 변경 사항을 가져와야 하는 경우 rebase 또는 merge 명령어를 사용할 수 있다.


Git merge

터미널에서 다음과 같이 merge 명령어를 입력한다.

git checkout feature  # feature 브랜치로 이동한다.
git merge master      # master의 작업 사항을 feature에 머지한다.

두 브랜치의 작업 사항을 합치는 merge 커밋이 feature 브랜치에 생성된다. 다음과 같은 흐름으로 master가 feature에 합쳐지면서 F3 merge 커밋이 생성된다.

merge master into feature master를 feature 브랜치에 merge

merge의 장점은 브랜치가 합쳐진 이후에도 각각의 커밋이 남아 있어서, 해당 브랜치의 작업 내역을 추적하기 쉽다.

하지만 브랜치를 합칠 때 마다 불필요한 merge 커밋이 남게되어 로그가 복잡해질 수 있다. 다음은 추가 커밋을 생성하지 않고 브랜치를 합칠 수 있는 rebase에 대해서 알아보자.


Git rebase

rebase는 이름대로 base를 재설정한다는 의미이다. 브랜치를 딴 시작 지점이 base가 되는데, M2 가 feature 브랜치의 base가 된다.

터미널에서 다음과 같이 rebase 명령어를 입력한다.

git checkout feature  # feature 브랜치로 이동한다.
git rebase master     # feature 브랜치에서 master를 rebase 한다.

rebase 작업은 master 브랜치의 변경 사항을 모두 가져와서 feature 브랜치를 master 끝부분에서 시작하도록 한다. 그리고 항상 변경 사항부터 기존의 feature 커밋이 모두 새로운 커밋으로 생성된다.

rebase의 가장 큰 장점은 커밋 히스토리가 깔끔해진다는 것인데, 불필요한 merge 커밋이 생성되지 않기 때문에 다음과 같이 선형의 히스토리를 가지게 된다.

rebase feature with master feature 브랜치에서 master를 rebase

The Golden Rule of Rebasing

rebase할 때 주의해야 할 점이 있는데, public 브랜치에서는 rebase를 하지 말아야 한다는 것이다. 예를 들어 위의 예시와 반대로 master 브랜치에서 feature 브랜치를 rebase하는 경우를 가정해보자.

rebase master with feature master 브랜치에서 feature를 rebase

rebase를 하게 되면 위와 같이 master의 모든 커밋이 feature의 끝부분에 위치하게 된다. 여기서 문제점은 다른 팀원들이 master에서 작업을 하는 경우이다. rebase를 하면 새로운 커밋을 생성하기 때문에 다른 팀원들과 master의 이력이 달라지는 상황이 생긴다.

서로 다른 두 브랜치를 동기화하려면 merge를 해야 하는데 역시나 불필요한 merge 커밋이 생기게 되고, 같은 변경 사항을 가진 커밋이 두 세트씩 생성된다. (원본 master 브랜치와 rebase한 master 브랜치)

꼭 rebase를 하기 전에 “이 브랜치를 바라보고 있는 다른 작업자가 있는가?” 를 생각하고 public 브랜치를 rebase할 때 신중하게 선택해야 한다.


Merge vs. Rebase


참고