예를 들어서 이해를 해봅시다.
위와 같이 커밋2에서 피쳐브랜치를 딴 상황이 있다고 가정해봅니다.
위 상황에서 브랜치가 파생되는 커밋2를 우리는 베이스라고 합니다.
1. Rebase
리베이스(rebase)는 파생된 피쳐브랜치의 기준이 되는 base 커밋을 변경하는 것입니다.
왜 리베이스를 사용해야할까요?
단순하게 커밋의 진행모습을 단순화 하기 위함입니다.
많은 사람들이 진행하는 레퍼지토리는 보통 브랜치가 많아지고, 그렇게 되면 커밋을 관리하고 파악하기가 어렵습니다.
그렇기에 뭔가 확인이 필요할 때마다 꼬여있는 커밋을 하나하나 확인하면서 진행해야하는 경우가 발생합니다.
그러나, 리베이스는 코드의 베이스 분기점을 변경해서 깔끔하게 만듭니다.
여러갈래로 갈라지지 않아서 커밋의 진행 사항을 훨씬 쉽게 파악할 수 있습니다.
예를 들어, 위의 그림에서 feature/A 브랜치를 develop 브랜치에 rebase 한다면
아래 그림처럼 변경됩니다.
위의 그림처럼 리베이스는 피쳐 브랜치 A의 base 커밋인 커밋2를 develop 브랜치의 마지막 커밋인 커밋6으로 변경합니다.
그리고 모든 브랜치의 커밋들을 리베이스 된 커밋 6 이후로 재정렬합니다.
2. Rebase vs Merge
흔히 사용하는 머지(merge)와 비교해 봅시다.
우리는 보통 피쳐브랜치에서 develop브랜치로 머지해야할 때, 우리가 작업하는 동안 다른 작업자들이 develop 브랜치에 커밋을 올리면
머지하기 전에 develop 브랜치에서 피쳐브랜치로 역머지를 진행한 뒤, 다시 develop 브랜치로 머지합니다.
그럼 아래와 같은 상황이 발생합니다.
위의 그림에서 c8, c9 커밋은 merge 커밋입니다.
리베이스를 했을 때의 모습을 확인해봅시다.
우선, merge 커밋이 하나(c7)만 생성되었고, 브랜치 트리가 훨씬 깔끔하게 된 것을 볼 수 있습니다.
사실 저렇게 그림으로 보면 잘 와닿지 않기에, 깃 크라켄으로 깃 그래프를 보면서 실습을 해보겠습니다.
아래와 같은 상황입니다. 위의 가장 첫번째 그림과 같은 상황이라고 보면 될 것 같습니다.
feature/test를 master 브랜치에 Merge를 해야할 때, Merge와 Rebase로 진행했을 때 차이를 보겠습니다.
Merge
역머지와 머지를 같이 하면 다음과 같이 그래프가 남고, Merge 커밋이 두 개나 남는 반면
Rebase
리베이스를 한번 하니, 그 전의 feature의 모든 커밋이 master 2 commit을 시작점으로 삼아 커밋이 올라가는 것을 볼 수 있습니다.
추가로 merge 커밋 역시 한 번만 남게 됩니다.
이런 것들이 하나하나 쌓이다보면 훨씬 깔끔한 깃 그래프를 만들 수 있고, 이는 앞으로 히스토리 파악이 필요한 경우에 모두에게 도움이 될 수 있습니다.
