PR 올리기 직전: Merge vs. Rebase

김기환·2022년 8월 7일
0

목적

Pull request를 올리기 전에, 나의 브랜치가 master와 fast-forward 상태가 되도록 만든다.

💡 "fast-foward"는 충돌 없이 바로 병합될 수 있는 상태를 말한다.

방법 1: Merge

절차

  1. master의 최신 상태를 내 브랜치에 merge시킨다.
  2. master와 내가 똑같은 파일을 고쳤다면 conflict가 날 것이다. 그럼 해결한다.
  3. 해결해서 만들어진 merge commit을 push한다. (merge commit이 새로 하나 생김)

장점

쉽다. 한 번의 merge 명령어만으로 쉽게 해결이 가능하다.

단점

커밋 내역이 지저분해진다. merge commit은 보통 관심이 없기 때문이다.

방법 2: rebase

rebase란 내 브랜치의 base를 master의 최신 상태로 옮기는 것을 말한다.
rebase의 원리는 기록 조작이다. 내 브랜치가 master의 최신 커밋에서 생성된 것처럼 조작하는 것이다.
실제로 해보면, 내가 원래 딴 커밋에서부터 내가 목표하는 base 커밋까지 하나씩 옮겨가면서 새로 커밋을 하는것이다.

절차

[(커밋 A) --- (커밋 B) --- (커밋 C)] 
  ㄴ--- (내 브랜치 커밋)
 
// (커밋 C)을 베이스로 리베이스를 실행한다
[(커밋 A) --- (커밋 B) --- (커밋 C)] 
               ㄴ--- (내 브랜치 커밋) // 한 커밋씩 옮겨가며 commit한다. 컨플릭이 나면 고쳐준다.
 
(Continue rebase를 누른다)
[(커밋 A) --- (커밋 B) --- (커밋 C)] 
                           ㄴ--- (내 브랜치 커밋) // 목표하는 (커밋 C)까지 왔다. 컨플릭이 나면 고쳐준다

장점

merge commit없이 깔끔한 커밋 히스토리를 만들 수 있다.

단점

  • 귀찮다. 만약 모든 사이 커밋들에서 충돌이 발생한다면 이를 해결하는게 오래 걸릴 수 있다.
  • 위험하다. 기본적으로 기록을 조작하는 위험한 작업이다. push 할 때도 --force 옵션을 켜야한다.

기타

  • merge --squash를 하면 merge의 단점인, 쓸모 없는 merge commit이 생기는 문제를 없앨 수 있다. 다만 의미있는 commit들도 날아갈 수 있다. 보통 develop과 feature 브랜치 간 병합의 경우, feature의 복잡하고 지저분한 커밋 히스토리를 굳이 남길 이유가 없어서, merge --squash를 쓰는 것이 좋다고 생각한다.
  • 보통 push를 준비하면서, pull을 하게 되는데, git pull 명령을 실행할 때 기본적으로 --rebase 옵션이 적용되면 편리하다.
git config --global pull.rebase true
profile
Front-end dev · Human-Computer Interaction

0개의 댓글