TIL 2022-03-17 git rebase, 3-way merge

rebase -i

 

git rebase -i로 기존에 올린 커밋들을 하나로 통합할 수 있다.

 

HEAD~3 등으로 범위를 정할수 있고, 이렇게 정해서 rebase를 하면

 

 

pick d94e78 Prepare the workbench for feature Z     --- older commit
pick 4e9baa Cool implementation 
pick afb581 Fix this and that  
pick 643d0e Code cleanup
pick 87871a I'm ready! 
pick 0c3317 Whoops, not yet... 
pick 871adf OK, feature Z is fully implemented      --- newer commit

이런 커밋들과 pick 등의 단어가 붙은 에디터창이 뜬다.

 

pick은 커밋 메시지를 수정하지 않고 그냥 사용하겠따

reword는 커밋 메시지를 사용하지만 수정함,

edit은 커밋 메시지뿐만 아니라 작업 내용도 수정 가능

squash는 이 커밋을 이전 커밋과 합쳐버림

fixup은 squash처럼 합치지만 커밋 메시지는 이전것만 남겨둠

drop은 해당 커밋을 삭제해버림!

 

 

3-way merge

git은 merge할때 공통선상에 있는 커밋들이 아니라면

1. 내 브랜치 커밋

2. 상대 브랜치 커밋

3. 공통 브랜치 조상 커밋을 비교하여 merge한다.

 

Base를 가짐으로써 충돌되는 부분과 변경된 부분을 확실하게 파악할 수 있다.

 

 

merge할때 옵션을 주어 다양한 방법으로 머지할 수 있는데

1) --ff  
$ git merge {병합할 브랜치 명}    
merge를 진행할 때 아무 옵션을 주지 않는 경우이며, 위에서 살펴보았던 Merge 방법과 
동일하다.   
현 브랜치와 병합할 브랜치가 Fast-forward 관계이면 Fast-forward 병합을 진행하며, 
 그렇지 않은 경우는 Merge 커밋을 생성하여 3 way-merge를 진행한다.   


2) --no-ff   
$ git merge --no-ff {병합할 브랜치 명}
현재 브랜치와 병합 대상의 관계가 Fast-forward관계 여부와 상관없이 
Merge 커밋을 생성하여 병합한다.     


3) --ff-only   
$ git merge --ff-only {병합할 브랜치 명}   
현재 브랜치와 병합 대상의 관계가 Fast-forward인 경우에만 병합을 진행한다. 
Merge 커밋 생성되지 않는다.   


4) --squash
$ git merge --squash {병합할 브랜치 명}  

 

어제 rebase 이야기

 

어제 작성한

지금 해보긴 했는데 이론적인 부분 많이 부족해서 내일 다시 공부해야겠다.
왜 branch_fix rebase 이후에 원격 레포의 origin/branch_fix에 push하면
pull origin branch_fix: Merge made by the 'recursive' strategy.
에 의해 merge가 형성되는 것?????? force push로 강제로 넣어주긴 했는데 왜인지 이유를 알아야겠다.

는 rebase가 형태는 동일해도 완전히 새로운 커밋을 만드는 것이고,

 

기존의 커밋들이 들어있던 origin의 브랜치와는 다른 헤드를 갖게 되어 recursive merge가 자동적으로 일어나는게 아닐까?

 

A rebase creates entirely new commits.

This means that if you try to push a branch that has been rebased locally—but not on the remote—the remote repository will recognize that the commit history has changed, and it will prevent you from pushing until you settle up the differences:

 

라고 적혀있다.