git rebase 동작 과정, 주의사항, merge vs rebase

 

git rebase : 한 브랜치의 변경사항을 다른 브랜치 위로 재배치시키는 명령어

 

Rebase의 장점

1. 병합 커밋이 없어 커밋 히스토리를 깔끔하게 정리 가능하고 가독성이 좋음
2. 특정 기능에 대한 커밋들을 연속적으로 볼 수 있어 코드 리뷰가 용이

 

Rebase 사용 예

두 개의 브랜치로 나누어진 커밋 히스토리

위 그림과 같이 두 개의 브랜치로 나누어진 커밋 히스토리를 합치고 싶은 상황에서 우리는 merge 명령을 사용할 수 있을 것이다.

$ git chekcout main
Switched to branch 'main'
$ git merge experiment
Merge made by the 'recursive' strategy.

merge 명령 실행시 현재 브랜치(main)가리키는 커밋(c3)가 merge할 브랜치(experiment)의 조상이 아니므로 3-way merge를 한다.

따라서 아래와 같이 merge commit(c5)가 생성되고 main 브랜치는 merge commit을 가리키게 된다.

git merge experiment 실행 결과

 

이와 동일한 결과를 rebase를 사용하면 merge commit 생성없이 깔끔한 커밋 히스토리를 유지하며 작업이 가능하다.

$ git checkout experiment
$ git rebase main
First, rewinding head to replay your work on top of it...
Applying: added staged command

 

 rebase 동작 과정

1. 공통 조상 찾기
   • 현재 브랜치(experiment)와 rebase 대상 브랜치(main)의 공통 조상을 찾음
2. 변경사항(diff) 수집
   • 현재 브랜치의 각 커밋들이 가지고 있는 변경사항을 수집
   • 이 변경사항들을 임시 파일로 저장
3. 브랜치 리셋
   • 현재 브랜치(experiment)를 rebase 대상 브랜치(main)의 최신 커밋으로 리셋
4. 변경사항 재적용
   • 임시 저장해둔 변경사항들을 순서대로 새로운 커밋으로 만들어 적용

 

rebase를 통한 c4의 변경사항을 main 브랜치 c3 위로 재배치

 

 

main 브랜치 포인터의 이동은 별도로 수행하지 않기 때문에 main 브랜치로 돌아와 Fast-forward하여 마무리한다.

$ git checkout main
$ git merge experiment

 

main 브랜치 Fast-forwarding

이처럼 rebase를 사용하면 일을 병렬도 진행한 상황에도 rebase 후에는 모든 작업이 차례로 수행된 것처럼 히스토리가 선형이 된다.

 

 

 

Rebase 사용 시 주의사항

• 이미 공개 저장소에 push한 커밋은 rebase하지 말기

발생 가능한 문제

• 다른 개발자가 기존 커밋을 기반으로 작업했을 경우
• 이미 push된 커밋을 rebase하면 팀 동료들의 작업에 혼란 초래
• 충돌과 중복된 커밋 발생 가능

문제 원인 : rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용만 같은 새로운 커밋을 만들기 때문

 

적절한 Rebase 사용 상황

• 로컬에서만 작업한, 아직 공유되지 않은 브랜치에서 사용
• main 브랜치의 최신 변경사항을 feature 브랜치에 적용하는 경우

 

Merge vs Rebase 어떤 것을 사용해야 될까?

Merge를 선호하는 관점

• 커밋 히스토리는 "실제로 일어난 일의 기록"이다.
• 히스토리는 역사적 문서로서 가치가 있다.
• 히스토리를 변경하는 것은 "거짓말"하는 것과 같다.
• 복잡한 merge 커밋들이 있더라도, 그것이 실제 작업 과정이므로 보존해야 한다.

Rebase를 선호하는 관점

• 커밋 히스토리는 "프로젝트가 만들어진 과정의 이야기"이다
• 책의 초고를 공개하지 않는 것처럼, 지저분한 작업 과정을 보여줄 필요가 없다.
• A에서 B로 가는 과정을 더 명확하고 이해하기 쉽게 만들어야 한다.
• 미래의 독자를 위해 더 나은 방식으로 스토리를 전달하자.

적절한 사용

• 로컬 변경사항은 rebase로 정리
• 이미 push한 내용은 절대 rebase하지 않기

 

참고 자료 :

https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Git - Rebasing

https://wikidocs.net/153961

05-05 rebase