Merge vs Rebase

Merge

branch를 통합하는 것

• 병합하고자 하는 브랜치의 모든 commit이 master의 commit으로 기록된다.
• -> 변경 내용 이력이 모두 그대로 남아 이력이 복잡함.
• pull을 실행한 뒤 다른 사람이 push를 하여 원격 저장소를 업데이트한 경우 내가 push 요청 시 거부됨.-> merge작업을 통해 다른 사람의 업데이트 이력을 내 저장소에도 갱신 필요.
• -> merge작업 없이 이력을 덮어쓰면 다른 사람이 push한 업데이트 내역이 사라짐.

Merge 종류

fast-forward

master 브랜치로 병합 시 master 브랜치에 변경이 없는 경우, master 브랜치의 이동 만으로 병합하고자 하는 브랜치 내용 적용 가능.

 

 

 

non fast-foward

master 브랜치로 병합 시 master 브랜치에 변경이 있는 경우,

master 브랜치 내의 변경 내용과 병합하고자 하는 브랜치 내의 변경 내용의 통합이 필요.

양쪽 변경을 가져온 merge commit 실행.

 

*fast-foward가 가능한 경우이더라도 브랜치로 실행한 작업 확인 및 관리를 위해 non fast-foward 옵션을 지정하여 병합 가능.

 

Merge 방식

3way merge

• git이 주로 처리하는 merge 방법
• base의 내용을 참고해 변경된 두 개의 branch의 내용을 비교하는 방식
• base의 내용과 비교해 수정된 쪽의 내용을 채택
• 두 branch 모두 변경된 경우 conflict 발생 (두 branch가 같은 부분을 다르게 수정했을 때)

2 way merge

• 변경된 두 개의 branch의 변경 내용만 비교하는 방식
• 두 branch의 내용 중 다른 부분의 경우 conflict 발생
• (한쪽은 수정, 다른 한 쪽은 수정하지 않은 경우 / 두 branch가 같은 부분을 다르게 수정했을 때)

---

Rebase

branch에 대한 base를 재설정한다.

• branch는 base 지점을 가지고 있어 base에서부터 코드를 수정한다.
• Git History가 깔끔해진다. - 개발자간의 배려
• 로그 관리에 효과적이다.
• 이력은 단순해지지만, 원래의 커밋 이력이 변경되기 때문에 정확한 이력을 남겨야 하는 경우 사용하면 안된다.
• rebase를 하는 경우, 병합하고자 하는 브랜치의 불필요한 commit은 생략하고, 필요한 commit만 남겨 master 브랜치에 병합하기 때문에 깔끔한 commit을 유지할 수 있다.
• 다른 사람과 공유하고 있는 branch에 push를 한 경우에는 사용하지 않는 것이 좋다.-> local에서 작업 후 push하기 전 commit 정리를 위해 사용하자! -> 내가 rebase한 내용을 다른 사람이 pull로 받는 경우 conflict가 발생할 수 있다.

 

 

rebase 진행방식

non fast-foward 방식의 경우,

 

병합하고자 하는 브랜치의 변경 내용을 master 브랜치의 base에 적용. ($ git checkout bugfix / $ git rebase master bugfix)

master 브랜치 base가 병합하고자하는 브랜치를 가리킬 수 있도록 merge ($ git checkout master / $ git merge bufix)