[git] merge VS rebase

브랜치를 병합할 때, rebase와 merge는 흔히 사용이 되는 명령어들이다. 하지만 헷갈릴 수 있으니, 이번 포스팅에서 두가지 명령어의 차이점에 대해서 간단히 포스팅 하겠다.

merge

merge는 말 그대로 브랜치를 합치는 작업을 한다. 특징은 각각의 브랜치의 커밋 히스토리가 모두 남는다.

예를 들면, main branch가 있고, 이 브랜치에서 파생된 ui-feature 브랜치가 있다고 해보자.

이 ui-feature 브랜치에서 작업을 했다고 가정하면, 그냥 이렇게 merge를 해줄 수 있다.

git switch main
git merge ui-feature

 

 

Fast forward merge 

Non-fast forward merge

 

[conflict가 없는 경우]

브랜치를 main으로 바꾸고, ui-feature 브랜치를 merge하면 새로운 merge commit이 main 브랜치에 생긴다.

merge를 성공적으로 마친 브랜치는 더 이상 사용하지 않으니 브랜치를 지우면서 정리하는 경우도 많다.

(참고로 브랜치를 지우는 명령어는 git branch -d <branch_name> 을 사용할 수 있다.)

 

[conflict 있는 경우]

위와 똑같지만, 각 브랜치를 merge할때 충돌되는 변경사항이 있다면, 충돌이 난 부분을 file editor, VS Code등으로 열어서 직접 조쳐준 뒤, 다시 git add + commit을 실행시켜주면 된다.

rebase

아까와 같은 예시를 들어보겠다.

rebase는 커밋을 다른 브랜치에 옮겨서 새로운 배이스를 갖는다고 표현할 수 있다.

rebase같은 경우 무서워 보이지만, 위와 비슷한 예시를 통해 보면 잘 이해할 수 있을 것이다.

 

일단, rebase는 한 브랜치를 기준으로 잡는다.

main 브랜치를 기준으로 잡고, ui-feature을 main 브랜치로 rebase하고 싶으면 이렇게 된다:

 

main 기준

git checkout ui-feature
git rebase main

 

이렇게 보이는 대로, main의 마지막 커밋 위에 ui-feature의 커밋들이 정렬이 되는 것을 볼 수 있다.

주의해야할 점은 ui-feature 커밋들이 그대로 옮겨진게 아니라, 새로운 hash commit이 생긴다. 내용은 같지만 hash commit이 다르기 때문에 다른 커밋이다.

ui-feature 기준 (비추천)

위와 다르게 메인을 ui-feature로 잡으면 어떻게 될까?

git checkout main
git rebase ui-feature

 

이런식으로 정력이 되는 것을 볼 수 있다.

왜 이 버젼은 비추천이냐면 보통 이렇게 하지 않고 경우 1로 하는 경우가 (main 브랜치를 기준으로 하는 경우) 대부분이기 떄문이다.

 

main을 기준으로 잡은 경우와 ui-feature을 기준을 잡은 경우 둘다 기준으로 잡은 브랜치의 커밋은 움직이지 않는게 특징이다. (또 합치려면 merge를 통해 해결하면 된다).

 

rebase는 merge와 같이 실행할때 conflict이 생길 수 있는데, 그럴때면 그냥 merge때와 같이 해결해주고 명령어를 다시 실행해주면 된다.

 

어느 명령어를 써야할까?

상황/회사/프로젝트에 따라 다르긴 한데, 커밋 히스토리를 깔끔하게 정리하고 싶을때는 git rebase를, 그리고 커밋 히스토리와 데이터를 보존하고 싶을 때는 git merge를 쓰면 될것 같다.