[Git] rebase is cleaner (merge vs rebase)

 

Git base로 개발을 수행하다 보면

commit -> pull -> merge -> push만 반복적으로 수행되는 경우가 많습니다

 

 

참여하는 개발자들이 많아질수록 merge가 자주 발생하게 되고

Git HIstory가 지저분해집니다(Non-linear history)

 

 

 

 

Non-linear history가 있으면 안되는가?

git든 현실이든 history는 다시 보기 위해 만들어두는 기록입니다

수많은 merge로인해 불필요하고 헷깔리는 commit들이 발생합니다

이러한 지저분한 기록보다는 다듬어두고 정리해두는게

훨씬 더 유용한 History를 유지할 수 있습니다

 

 

Linear History를 유지하기 위해 추천하는 방법은

rebase를 적극적으로 활용하는 것입니다

 

 

remote의 코드를 local로 pull할 때, local에 commit된 코드가 있으면

merge 대신 rebase를 수행하여 Linear HIstory를 유지할 수 있습니다

rebase를 사용하면 전혀 문제 없이 history가 정리되며

정확히 commit을 확인하고 관리할 수 있습니다

 

 

아래 그림을 통해 간단히 비교해봅시다

 

 

상세 과정을 비교해보면 아래와 같습니다

commit -> pull -> merge -> push

commit -> rebase -> push

 

 

위에서 rebase가 얼마나 세련되었는지 파악할 수 있습니다

앞으로의 편한 git 생활을 위해 아래와 같이 설정해두도록 합시다

git config --global pull.rebase true
git config --global rebase.autostash true

 

 

해당 설정을 사용하면 'git pull'은 항상 'git pull --rebase'로 동작하고

commit 안된 변경사항은 자동으로 stash되었다가 pop이 수행됩니다

(실수로 rebase 대신 그냥 pull을 수행하지 않을 수 있고,

commit되지 않은 코드가 있어도 깔끔하게 rebase가 수행됩니다. 넘 편한것)

 

 

그럼 merge는 쓸모 없는것이냐? 그렇지 않습니다

일반적으로 발생하는 불필요한 merge는 위의 그림에서 봤듯이

local branch와 remote branch가 merge되는 경우입니다

 

 

이러한 경우는 단정한 linear history를 유지하기 위해 rebase를 사용하고

main(master) branch가 아닌 remote에 생성되어 있는

branch 간의 merge의 경우만 merge로 표시되어야

보기좋은 history가 유지됩니다(정말 필요한 merge)

 

 

---

 

 

위의 방식이 정답은 아닙니다

하지만 정답처럼 많은 개발자가 사용하고 있기도 합니다

극적인 merge와 rebase의 history 차이

 

 

아래처럼 다른 관점도 있으니

팀이 큰 경우에는 전략에 따라

해당 사항을 고려해 두시기 바랍니다 

 

 

[Reference]

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

https://www.bitsnbites.eu/a-tidy-linear-git-history/

https://velog.io/@godori/Git-Rebase

https://velog.io/@gil0127/Git-merge-Git-rebase