Git의 rebase를 이용한 커밋 정리 (merge와 차이)

Git을 처음 입사 후 진행했던 프로젝트에서 Gitlab을 통해 처음 접해보았다.

확실히 저장소 관리하는 방식과 커밋 전 단계가 제공되는 것 등등 편한 것이 많았다. 하지만 그 때 당시 딱히 팀원이 없었기에 히스토리 관리 및 flow 관리를 해야한다는 필요성을 알지도 못했고 듣지도 못했었다.

그러나 공부를 진행해보면서 git에 rebase라는 좋은 기능이 있다는 것을 알게되었고 배워보고 싶어 nhnent에서 제공하는 사내 교육에 참여하였다.

우선 첫 번째 글로 rebase와 merge에 차이를 설명하고 rebase를 진행해보자.

rebase란? 우선 rebase는 base를 다시 지정한다 (re-base)의 의미이다. base가 무엇인가? 다음 그림을 보자.

그림을 보면 master의 c4와 experiment 브랜치의 c3 커밋이 있다. 두 개의 커밋은 c2라는 같은 조상에서 시작되었다. 바로 이 c2가 base이다. 그럼 이 베이스를 다시 한다는 것은 어떤 의미일까?

여기서 중요한 개념이 rebase와 merge에 차이이다.

그림을 보면 두 개의 master와 experiment 브랜치는 서로 merge를 하였고, 그러면서 새로운 c5 커밋이 생겼다. 이 두개의 커밋이 합쳐져서 이제 하나의 뿌리로 시작하겠지만 커밋 히스토리를 보게되면 위와 같이 뿌리가 나눠져 있어서 히스토리를 찾아갈 때 보기가 어렵다.

이건 단순한 한가지 코드지만 만약 브랜치가 엄청 많아진다면? 정말 히스토리를 보기 어려울 것이다. 그렇기 때문에 리베이스 개념이 사용되는데 베이스를 다시 재정의하여 새롭게 커밋라인을 정리하여 히스토리를 깔끔하게 볼 수있게 해준다.

이 그림이 rebase가 완료된 그림이다.

브랜치가 사라지고 두 개의 브랜치의 base였던 c2를 기준으로 정리가 된것을 볼 수있다.

rebase 단계 계산 및 진행과정

현재 위와 같은 상황이라고 가정해보자. 현재 head는 feature 브랜치에 있고 아래 master branch를 향해서 rebase를 진행할 것이다.

그러면 c2까지의 변경내용에 대해 계산을 선 진행한 후 다음과 같이 변경 내용들을 master 브랜치 앞에 붙힌다.

그리고 master 브랜치를 새로 리베이스된 커밋 앞으로 fast-forward를 진행하면 다음과 같이 완료된다.

그럼 리베이스를 실습해보자.

rebase 하기

git의 기능을 편리하게 사용할 수 있도록 제공해주는 sourceTree를 사용해서 진행해보겠다.

우선 저장소를 먼저 생성하고 마스터 브랜치에 새로운 파일을 하나 추가하고 첫 번째 커밋을 진행한다.

그리고 마스터 브랜치에 파일을 하나 더 추가하고 한번더 커밋을 제공하면 다음과 같이 히스토리를 볼 수 있다.

그리고 feature 브랜치를 하나 생성한다.

생성이 완료된 feature로 체크아웃한 후 두 개의 커밋을 더 진행한다. 그리고 마스터로 돌아와서 한번도 커밋을 진행하면 다음과 같은 히스토리를 볼 수 있다.

그럼 여기서 feature 브랜치의 내용을 master로 rebase를 진행해보겠다.

우선 feature 브랜치로 checkout 진행 후 sourceTree에서 master branch를 우클릭한 후 현재 변경사항을 master에 재배치를 선택한다.

그러면 다음과 같이 rebase가 진행된 것을 볼 수 있다. 깔끔하다!

그럼 fast-forward 까지 진행하고 마무리 해보자.

회사에서 지금은 웹팀으로 옮겨서 SVN을 사용중이다. 물론 SVN이 심플해서 우리회사에는 더 어울리는 것 같다. 그래도 요새 대다수가 사용하는 git에 대해 항상 더 알고싶었는데 기회가 있어서 교육을 들어 좋았다.

계속해서 다양한 사례에서 rebase를 진행하는 걸 알아보자.