간략하게 나타내면 아래와 같은 상황

현재 이런 브랜치 상황이고

 

중간에 깃 머지를 하고 일어나는

충돌은 이제 자연스럽게 진행을 해준다.

 

그리고 $ git history --all --graph를 하면 아래와 같이 머지가 잘 된것을 볼수 있다.

이러한 방식은 굳이 git merge를 하지 않고 git rebase로도 가능하다.(git rebase를 하기 위한 큰그림..ㅋㅋㅎㅎ)

rebase는 베이스를 다시 지정하다. 즉 커밋을 재배치하는 것을 말한다.

즉 지금 같은 상황에서는 프리미엄 브랜치의 베이스를 테스트 브랜치로 재지정하는 것!

 

일단 다시 premium 브랜치를 머지하기 이전으로 돌리기 위해 리셋해주고

 

git rebase를 하면 머지와 마찬가지로 CONFLICT 가 뜬다!

 

자연스럽게 머지충돌과 똑같이 필요없는 부분을 편집해서 해결해주고

 

다시 돌아와서 add하고 git commit 대신 git rebase --continue를 입력한다.

--continue는 컨플릭트가 발생해서 제대로 진행되지 못한 리베이스를 계속 진행하라는 의미!

진행하고 확인해보면 커밋과는 다른 모양이된다.

 

비교하자면 아래와 같음! 머지를 한것처럼 갈래가 생기는게 아니라 원래 커밋한모습대로 나와있다는거!

즉 git rebase는 병합한 구조가 아니라 "Add get_Median function"을 거쳐온 것 같이

커밋 히스토리의 구조 자체가 바뀌게 된다.

 

요약하자면

merge와 rebase 의 차이는

1. rebase는 새로운 커밋을 만들지 않는다.

2. rebase로 만들어진 커밋 히스토리는

   merge로 만들어진 커밋 히스토리보다 좀 더 깔끔하다.

결과적으로는 동일하지만, 결국 커밋 히스토리를 깔끔하게 만드는게 중요한 경우에는 rebase를 쓴다고 한다..

당연히 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야 하는 경우라면 merge를 사용하고~ ^^

 

 

 

'EDU > codeIt' 카테고리의 다른 글

git cherry-pick  (0) 2021.11.04
git stash 와 스택  (0) 2021.11.04
MySQL 과제모음  (0) 2021.10.13
MySQL 서브쿼리와 뷰를 활용한 데이터 분석  (0) 2021.10.13
MySQL 테이블 조인을 통한 데이터 분석  (0) 2021.10.13

+ Recent posts