간략하게 나타내면 아래와 같은 상황
현재 이런 브랜치 상황이고
중간에 깃 머지를 하고 일어나는
충돌은 이제 자연스럽게 진행을 해준다.
그리고 $ 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 |