[Git] merge말고 rebase를 사용해야하는 이유, Rebase vs Merge

이 글을 쓰게 된 이유

벌써 회사에서 6개월이나 넘게 깃을 썼지만, 그럼에도 헷갈린당ㅜㅜㅜ

나 혼자 commit, push 할때는 그래도 괜찮은데 

문제는 다른 팀원들이랑 브랜치를 같이 써야야할 경우....git rebase가 문제다..

 

사실 사내에서는 git merge가 아닌 rebase를 하도록 컨벤션을 지정했는데,

내가 여기에 익숙하지 않다보니 rebase를 할때마다 헷갈린다..

그래서 깃도 꼬이고..브랜치 정리도 안되고..

(그래요 제가 죄인입니다😢)

 

그래서 이번에 git rebase 대해서 확실히 짚고 넘어가보려고 한다..!

 

---

브랜치 병합

예를 들어, 아래와 같이 2개의 브랜치가 있는 상황이라고 생각해보자

main 브랜치는 기존의 개발작업을 진행했던 브랜치고, 

새로운 피쳐를 추가개발해야해서 main에서 시작하는 feature branch를 만들었다. 

그리고 feature 브랜치로 개별적으로 개발이 완료된 후, 이걸 하나의 브랜치로 합쳐야한다.

이때 두가지 방법이 있다..!

 

 

Git Merge vs Git Rebase

 

 

Git Merge

내 기준 직관적이고 이해하기 쉬운 병합방식이다.

 

' feture '에'  main브랜치'를 합쳐야하는 상황 

$git chechkout feature
$git merge main

 

그래서 feature으로 checkout을 하고, feature에서 main브랜치를 merge한다.

즉, 아래의 그림처럼 feature에 main을 합치는 것(merge)이다! 

merge : main브랜치와 feature브랜치를 merge comiit으로 합칩

브랜치 변경 없이 단순히 브랜치를 합치는 거라고 보면 되는데,

대신 합쳤다는 커밋이 새로 만들어진다! 

 

그래서 Merge할때마다 merge commit이 무조건 한개씩 생기는데, 

프로젝트가 활발할 경우 merge commit 때문에 변경이력을 알기 어렵다.

어떤 변화가 언제 반영되었는지에 대한 이력이 없이 다 하나의 커밋으로 합쳐지기 때문이다. 

 

git merge 효과
방식 : 하나의 merge commit이 생성되면서 합쳐짐
장점 : 브랜치 변경 없이 merge하기 쉽다
단점 : 변경이력을 알기 어렵다는 단점도 있다.

 

 

Git Rebase

회사에서 지정한 브랜치 병합 방식이다. 조금 헷갈리지만 한번 이해하면 괜찮다!

팁이라면, 어떤 브랜치가 베이스고, 어떤 브랜치가 합쳐지는건지 그 기준으로 잘 이해하면 된다!

 

마찬가지로 ' feture '에'  main브랜치'를 합쳐야하는 상황 

$git chechkout feature
$git rebase main

그래서 feature으로 checkout을 하고, feature에서 main브랜치를 merge한다.

즉, 아래의 그림처럼 feature에 main을 합치는 것(rebase)이다! 

rebase : main브랜치 끝에 feature 브랜치의 커밋으로 이어붙임

위의 그림에서 보는 것처럼 feature에 main이 붙을떄, main의 끝이랑 feature의 시작이 이어진다!

main 브랜치 뒤에서 새로운 커밋으로 feature 브랜치의 커밋들이 줄줄이 생기는 것이다! 

 

main입장에서는 계속 커밋들이 이어지는 것인데,

그러다보니 각 commit마다 conflict가 일어날수가 있다...! 

그럴때마다 head가 계속 바뀌면서 rebase continue를 계속 해주었다....

 

하지만 덕분에 합쳐질 브랜치들의 커밋들이 다 남아 있기 때문에

git merge를 했을때보다 변경이력을 알기 훨씬 쉽다.

그러다보니 사내 컨벤션으로 git rebase를 사용하여 브랜치를 관리하는걸 기본으로 하고 있다.

 

용어 그대로 rebase, 베이스를 다시 지정한다는 것이다. 

git rebase 효과
방식 : rebase가 되는 베이스 브랜치(main)에 합쳐질 브랜치들(featrue)의 커밋이 새로운 커밋으로 각각 줄줄이 생기면서 합쳐짐
장점 : 변경이력을 알기 쉽다. (히스토리 관리용이)
단점 : 각 커밋마다 conflict가 일어날수 있다, merge하는 방식을 이해하기 어렵다...!

반응형

---

 

이 글을  쓰고 나서 느낀점 

우선 글을 쓰고 나서,  내가 실무에서 겪었던 깃 관련 trouble shooting을 더 공유하고 싶은 욕심이 생겼다.

 

예를들어 처음에 소스트리의 커밋기록 중에 같은 시간대로 커밋들이 여러개 생겨나서 그 이유가 궁금했었는데,

지금 생각해보니까 rebase 때문인것이다.....! 

그리고 마찬가지로 rebase를 했는데 conflict가 계속 나서 그걸 해결하는것도 일이였다...!

(이젠 pycharm에서 conflict solve로 해결하지..)

 

그래서 이런 조금 더 디테일한 사례들로 한번 더 git에 대해서 정리해보면 좋을것 같다는 생각이 들었고,

Rebase를 정리해본 덕분에 다음 rebase에서는 실수 안하고 제대로 잘할 자신도 생겼다..(정말..?🧐)

다음부턴 진짜 잘해야지..