git merge

fast-foward: 이미 같은 조상을 바라보고 거기에 연장선상의 커밋일 경우에는 그냥 기존 부모의 커밋이 앞으로 한단계 가는 fast-foward 형식으로 머지를 한다.

이 경우에 hotfix 브랜치를 master에 머지하면 fast-foward를 한다.

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

이렇게 된 경우에는 fast-foward를 할 수 없고, 3-way Merge가 진행된다.

이미 마스터가 내가 기초가 된 것보다 더 한단계 이동.

$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

두개의 커밋 결과를 하나의 커밋으로 합침. 그것의 결과를 별도 커밋으로 만들고 해당 커밋을 머지 당할 브랜치가 가리키도록 바꾼다.

아래같이 만들어진 머지 커밋은 부모가 여러개.

• git rebase

말그대로 베이스를 다시 한다 요런 말인것인데

요것에서 experiment 브랜치에서 git rebase master 를 하면 c3에서 변경된 사항을 patch로 만들고 이를 다시 c4에 적용시킨다.

이것이 바로 리베이스이다.

두 브랜치의 공통 커밋으로 이동

→ 해당 커밋부터 지금 checkout 브랜치의 커밋까지 diff 후 따로 임시 저장

→ rebase 할 브랜치(experiment)가 합칠 브랜치(master)가 가리키는 커밋을 가리키게 하고, 하까 저장해놓은 변경사항 차례대로 적용

즉, experiment가 master의 브랜치 변경을 베이스로 하여 자신의 변경을 추가로 얹어놓는것

experiment를 master에 rebase한 후 master에 experiment에 머지하면 머지 가능.

→ rebase를 하면 모든 작업이 차례대로 수행된 것 처럼 깔끔하게 적용된다. 커밋 히스토리가 깔끔해진다.

→ rebase 의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고 merge 의 경우는 두 브랜치의 최종결과만을 가지고 합친다.

rebase를 이용하면 다른 브랜치에 새롭게 자리를 잡아서 업무를 하는게 가능하다. 가령 이런 경우.

client branch의 변경만을 master에 머지하고 싶을 경우,

client를 master에 rebase, master에서 client merge

→ 이렇게 되면 depth와 상관없이 master에 머지할 수 있다.

rebase에는 주의할 점이 있는데, 이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라는 것이다.

rebase는 기존의 커밋을 그대로 사용하는 것이 아니라, 내용은 같지만 다른 커밋을 새로 만든다.