Rebase vs Merge

Rebase vs Merge

• 둘 다 분기된 브랜치를 하나로 합칠 때 사용하는 방법

공통 상황

• master에서 분기된 develop 존재
• 각 기능 개발을 위해 develop에서 feature/test 브랜치를 생성
• feature/test 브랜치에 commit 1,2,3이 커밋된 상황
• 그 사이에 develop 브랜치에 develop commit 1이 추가 커밋된 상황
• develop 브랜치의 develop commit 1의 작업 내용과 feature/test 브랜치의 commit 2는 같은 소스를 작업 (소스 충돌)

Merge

• 병합하고자 하는 브랜치의 변경사항을 현재의 브랜치의 최신 커밋 이력으로 남긴다.

 

Step #1

• 초기 작업 상황
• feature/test의 작업이 끝내고 develop으로 반영해야한다.

 

Step #2

• feature/test의 base가 된 develop 브랜치에서 추가 작업(develop commit 1)이 있었음
• develop의 추가 작업 내용을 feature/test에 반영하기 위해 merge develop into feature/test 실행
• 충돌나는 작업이 생김

 

Step #3

• 충돌 해결
• 충돌 나는 소스를 적절히 수정 후 푸쉬

Step #4

• 머지가 완료된 브랜치 현황
• 즉 병합하고자 하는 브랜치(develop)의 변경 사항들이 현재 브랜치(feature/test)의 최신 커밋 이력으로 남았다.
  • Merge branch 'develop' into 'feature/test'

Rebase

• 분기되어 빠져나온 브랜치(feature/test)의 base 브랜치(develop)를 다시 재설정(rebase)한다
• 역시 말로만 표현하려니 어렵다..

 

Step #1

• 초기 작업 상황
• feature/test의 작업이 끝내고 develop으로 반영해야한다.

 

Step #2

• feature/test의 base가 된 develop 브랜치에서 추가 작업(develop commit 1)이 있었음
• develop의 추가 작업 내용을 feature/test에 반영하기 위해 rebase feature/test onto develop 실행
• 아까와 마찬가지로 충돌나는 작업이 생김

 

Step #3

• 충돌 해결 후 머지하면 위와 같이 base(develop)를 최신 상태로 재설정하여 그 이후 feature/test 브랜치가 분기된 것 처럼 나온다

장/단점

• Merge
  • 편하다 ( 개인적인 생각.. )
  • 충돌 해결을 하기 직관적이다 ( 최종 이력이 생겼을 때 수정하면 된다 )
  • 단 커밋 이력이 지저분 해진다
• Rebase
  • 커밋 이력이 깔끔하게 남는다
  • 의미없는 커밋이 없어짐 ( Merge ..... )
  • 충돌 해결이 어렵다.. ( 각 충돌난 이력마다 처리해줘야한다 )
• 언제 어떤 것을 사용할까?
  • 이제부턴 개인적인 생각
  • base로 부터 분기가 된지 오래됐으면 merge를 쓰는게 정신 건강에 좋은 것 같다.. (rebase는 충돌 수정을 하나씩..)
  • 일반적으로 rebase를 우선순위로 생각하자 ( 커밋 이력이 깔끔한 장점이 명확 )
  • 만약 로컬에서 작업중인 feature가 origin에 push 됐다면 rebase하면 안된다.
    • rebase는 base를 다시 맞추는 것이기 때문에 commit history hash 값이 바뀐다
    • 만약 origin에 push된 feature가 있는데 develop을 rebase 후 push 하려고하면 아래와 같은 상황이 된다