Git merge command

설명을 시작하기에 앞서 commit이란 Git을 구성하는 중요한 요소 중 하나이며
원칙적으로 하나의 커밋은 의미있는 하나의 변경사항을 의미한다. 즉 커밋
메세지만 보고도 어떤 사항이 어떠한 이유로 변경 되었는지 쉽게 파악할 수 있어야 한다.

앞서 말한 commit들이 모여서 시간 순서로 정렬된 것을 commit history라고 말한다.

커밋 히스토리의 중요성

1. 버그가 발생했을 경우 잘 정리된 히스토리가 있다면 수정된 커밋만 찾아
   어떤 코드가 수정되었는지에 대해 빠르게 확인할 수 있다.


2. 레거시 코드를 수정하는 경우에도 당시의 개발자가 어떠한 의도로 코드를 수정했는지
   기록해 놓은 커밋 히스토리 밖에 없기 때문에 이것을 잘 관리하는 것이 중요하다.

3-way merge

비교를 위해 내 브랜치 커밋, 타인의 브랜치 커밋,
두 브랜치의 공통 조상이 되는 커밋 이렇게 3가지가 필요하다.

1. 서로 다른 브랜치에 공통되는 베이스 브랜치를 기점으로 충돌을 최소화 하는 방법


2. 결과를 별도의 커밋으로 만들고 해당 브랜치가 그 커밋을 가리키도록 이동한다.


3. 브랜치간 병합을 진행할 때 베이스를 기준으로 어떤 브랜치가 수정되었는지
   확인할 수 있어서 충돌 문제 해결에 효과적이다.

1) 병합되기 전 브랜치 상태

2) 병합 이후 브랜치 상태

Fast-Forward

두 개의 브랜치를 병합할 때 Git이 간단한 경우에 적용하는 최적화 기법

1. 서로 다른 브랜치의 베이스 커밋의 내용이 변경되지 않았을 경우 사용되고
   기존 master 브랜치에서 새로운 feature 브랜치 하나를 생성한 뒤에 master에선
   더 이상 커밋하지 않고 feature에서만 커밋하는 경우에 Fast-Forward 방식으로 합병된다.


2. 이 경우에는 merge 커밋이 별도로 생성되지 않고 HEAD의 위치만 이동한다.

1) 병합되기 전 브랜치 상태

2) 병합 이후 브랜치 상태

Rebase

리베이스란 말 그대로 base를 재설정한다는 뜻으로 하나의 브랜치가 다른 브랜치에서
파생되어 나온 경우 다른 브랜치에서 진행된 커밋을 다시 가져와 base를 재설정하는 것이다.
새로운 커밋을 기반으로 작업을 함으로써 파생된 브랜치는 병합 시
conflict 없이 자신의 브랜치에 진행된 커밋을 반영할 수 있다.

병합을 하면 아래의 사진과 같이 main 브랜치의 커밋을 feature 브랜치로
병합 함으로써 feature 브랜치에 새로운 커밋이 발생하게 된다.

반면 rebase를 하게 되면 하늘색의 새로운 main 브랜치의 커밋을 포함해 rebase를 함으로써 마치 하늘색 커밋들이 처음 커밋된 것처럼 선형 히스토리를 남길 수 있게 된다.

참고 자료 및 블로그 :

커밋, 커밋 히스토리
패스트포워드, 3 방향 병합
리베이스 참조 블로그