본문 바로가기
혼자 공부하는 것들

[Git] rebase와 merge의 차이점

by applepick 2021. 8. 28.
반응형

merge와 rebase의 차이점이 무엇이고 어떠한 상황일 때 사용하는지 정리해보려고 합니다.

 

https://applepick.tistory.com/99?category=800640

 

Git-flow를 사용해보자!

회사에서 서비스 기능을 구현하기 위해 git develop 브랜치에 올리려고 하였다. 전 게시글에서 보았듯이 develop 브랜치는 다음 버전을 개발하는 브랜치라서 잘못 올렸다가는 master에 merge가 되어 배

applepick.tistory.com

제 블로그에 git-flow에 대해서 정리한 것이 있으니 한번 참고해보셨으면 좋을 듯합니다.

merge

merge는 흔히 브랜치를 병합하는 것으로 많이 사용합니다. 

예를 들어보겠습니다. develop 브랜치에서 feature 브랜치를 하나 만들어서 게시판을 개발합니다. 개발이 끝난 뒤 develop 브랜치에 merge를 함으로써 개발 완료된 것을 합쳐줍니다. 이때 feature 브랜치에 있던 커밋 기록이 develop 브랜치에 합쳐지게 됩니다. 

rebase

rebase는 말 그대로 현재 브런치를 베이스로 기준을 잡아 합치는 것입니다. 특징으로는 중복 로그를 남기지 않고, merge log를 줄여 히스토리를 깔끔하게 정리할 수 있습니다. 자세한 설명을 위해 사진을 보면서 정리해보겠습니다.

 

예를 들어 게시판 기능을 개발하는 feature f1 ->f2 브랜치를 완성된 뒤  개발 완료된 M2 브랜치를 바로 이어서 붙이고 싶다면 rebase를 사용하면 됩니다.  rebase를 이용하면 이런 식으로 붙여지게 됩니다.

단점으로는 public branch에서 사용하면 안 됩니다. push 한 commit을 팀원분이 pull로 받아 체크아웃한 뒤 내가 rebase를 한다면 충돌이 일어납니다. 본인의 repository에서의 해당 브랜치 위치와 다른 팀원들의 해당 브랜치 위치가 달라집니다. 합치려면 다시 한번 merge를 해줘야 하는 번거로움이 있습니다.

 

분명히 두 방법도 장단점이 있습니다.

히스토리를 보는 이유 중 하나가 작업한 내용의 기록을 보는 것입니다. 로컬 브랜치에서 수많은 merge commit을 정리하려면 rebase가 좋은 방법 일 수 있습니다. 어딘가 push로 던진 커밋에 대해서는 rebase를 사용하면 안 됩니다.

 

결론은 "이미 공개 저장소에 push 한 커밋은 rebase 하지 말자"입니다. 

 

반응형

댓글