[Git] Git Rebase

Git rebase는 브랜치를 병합할 때 기존의 커밋 기록을 그대로 유지하지 않고, 새로운 커밋 기록으로 재정렬하여 보다 깔끔하고 선형적인 히스토리를 만드는 방식이다. 일반적으로 기능 개발을 위해 feature 브랜치를 만들면, 그 동안 main 브랜치는 계속 업데이트되고 커밋이 쌓인다. 이때 feature 브랜치는 main보다 뒤쳐지게 되는데, rebase는 feature 브랜치의 시작점을 main의 최신 커밋으로 옮겨서 마치 feature 브랜치가 최신 시점부터 개발된 것처럼 히스토리를 새로 쌓는 효과를 만든다.

rebase가 수행되면 기존의 커밋들은 새로운 부모 커밋을 기준으로 다시 쓰여지기 때문에, 보기에는 동일한 작업처럼 보이지만 사실상 새로운 커밋 ID를 가진 히스토리가 만들어진다. 따라서 협업 시 이미 push된 브랜치를 rebase하면 충돌이나 재작성된 히스토리로 인해 팀 전체가 혼란을 겪을 수 있어, 주로 혼자 작업한 로컬 브랜치에서만 사용하는 것이 안전하다.

예를 들어 main 브랜치에 다음과 같은 커밋이 있다고 가정한다.

A — B — C (main)

그리고 feature 브랜치에서는 다음처럼 작업이 이루어졌다고 하자.

A — B — D — E (feature)

그 사이에 main이 업데이트되었다면 히스토리는 다음과 같이 갈라져 있을 것이다.

A — B — C (main) \ D — E (feature)

이때 git rebase main을 feature에서 실행하면 feature 브랜치가 다음과 같은 모습으로 재정렬된다.

A — B — C — D’ — E’

여기서 D’, E’는 내용은 같지만 새롭게 재작성된 커밋이다. 결과적으로 feature 브랜치는 마치 C 이후에 개발된 것처럼 보이며, 병합 시 사용되는 merge commit도 만들 필요가 없어진다.

실사용 사례로는 다음 상황이 자주 발생한다. 회사에서 main 브랜치에 최신 배포 코드가 있고, 개인이 로컬에서 feature를 개발하고 있을 때 pull 요청 전에 main의 최신 변경사항을 반영하려면 일반적으로 merge를 할 수도 있지만, merge를 하면 히스토리가 다음과 같이 복잡해진다.

A — B — C —— G (feature merge commit) \ / D — E

이런 방식은 기록이 지저분해지고, 여러 기능 브랜치가 동시에 merge되면 히스토리가 난잡해진다. 반면 pull 요청 전 rebase를 수행하면 feature 브랜치는 정돈된 하나의 선형 흐름으로 처리될 수 있다.

결과적으로 rebase는 새로운 커밋처럼 재작성되는 단점이 있지만, 복잡하지 않은 로컬 작업을 정리하고, 깔끔한 히스토리를 유지하고, merge commit을 줄이고 싶을 때 적합한 방식이라 할 수 있다. 협업 시에도 리뷰어가 보기 좋은 기록을 만들 수 있기 때문에 조직에서도 자주 선택되는 전략 중 하나이다.

참고