[ GIT ] 브랜치 병합 전략 Merge VS Rebase

• 브랜치 병합 전략이란?

여러 사람들이 작업을 하다보면 각 브랜치를 하나로 합치게 되는 경우가 있다.

Git 에서는 일반적으로 두가지의 방법을 사용하여 브랜치를 병합한다.

Merge

Rebase

Merge 는 자주 사용해서 익숙하나 Rebase는 잘 모르겠다. 그래서 알아본다.

1. Merge

Merge 브랜치의 전략 = 3 - way merge 를 수행하여 새로운 커밋을 만들어 내는 것

1. 내 브랜치 커밋

2. 남 브랜치 커밋

3. 두 브랜치의 공통이 되는 커밋

2. Rebase

두 브랜치의 공통 조상이 되는 base를 다른 브랜치의 커밋 지점으로 바꾸는 것 = base 를 rebase!

rebase 수행 후, 얻고자 하는 목적은 master 브랜치의 마지막 커밋 이후에 작업한 브랜치가 일어난 것 처럼 히스토리를 변경한다.

즉, feature의 base를 가장 최신의 master 커밋으로 재설정(rebase) 한다.

Rebase 브랜치의 전략

=

1. rebase 하려는 브랜치 커밋들의 변경사항을 patch 라는 것으로 만든 후, 어딘가 저장한다.

2. 이를 master 브랜치에 하나씩 적용하여 새로운 커밋을 만든다. ( base 커밋 -> 최근 마지막 커밋 )

3. 최근 마지막 커밋 까지 rebase가 완료되면, patch를 master에 fast-forward merge

[ feature를 master 브랜치로 rebase하는 명령어 ]

1. feature 브랜치로 checkout

2. master 브랜치로 rebase

3. feature 브랜치를 master로 fast-forward merge

• fast-forward merge?

master을 base로 작업 브랜치를 따고 다시 master에 merge 할 때,

master 의 상태가 이전부터 변경되어 있지 않으면 매우 쉽게 병합할 수 있다.

즉, 작업 브랜치가 master 브랜치의 이력을 모두 포함하고 있기 때문에 단순히 이동만 해도 작업 브랜치의 내용을 적용할 수 있다.

이 같은 병합을 'fast-forward(빨리 감기) merge'이라고 부른다.

• non fast-forward merge?

master을 base로 작업 브랜치를 따고 다시 master에 merge 할 때,

master 의 상태가 여러 가지 변경 사항이 적용되는 경우에는 master 브랜치 내의 변경 내용과 작업 브랜치의 변경 내용을 하나로 합친다.

따라서, 양쪽의 변경을 가져온 'merge commit(병합 커밋)' = 'non fast-forward(빨리 감기) merge' 이다.

이는 브랜치가 그대로 남기 때문에 그 브랜치로 실행한 작업 확인 및 브랜치 관리 면에 유용하다.

그래서 일부로 'fast-forward merge'가 가능해도 'non fast-forward merge' 옵션을 추가하기도 한다.

• Merge VS Rebase

Merge 와 Rebase 는 통합 브랜치에 토픽브랜치를 통합하자는 목적은 같으나,

Merge는 변경 내용의 이력이 모두 남고 Rebase는 이력이 단순하나 변경이 되므로 히스토리 관리가 안됨