- git을 사용하며 자주 사용되게 되는 명렁어이다
- 특히 브랜치를 병합할때, "Merge","Rebase"를 사용할것입니다
- 하지만 정확한 원리는 이해하지못하고, Rebase는 커밋내역 이쁘게 합치기, Merge는 단순 병합시키기 정도로만 이해하고 넘어갔는데, 오늘은 그 부분에 대해 세밀하게 이해해보려고한다!
시나리오
- 초록색 : master-branch
- 노란색 : sub-branch
Merge
- Merge라는 이름만 보았을때, Branch를 병합 해주는 작업같다
- 그렇다면 한번 초록색의 master 브랜치에서, 노란색의 sub 브랜치를 git merge 병합을 실행해보자
- master에서 merge를 실행한 결과, master 브랜치의 HEAD에서 새롭게 커밋이력이 생성된 것이 확인됩니다
- 이 과정에서, 초록색 master 브랜치와 노란색 sub 브랜치에서 같은 부분을 건드린다면 conflict오류가 발생 할 수 있습니다
코드와 함께 봐보자
- git merge를 테스트할 파일을 하나 만들어주자
- main,sub 브랜치를 만들어준다
- main브랜치에서 MainTestOne 클래스를 만들고 커밋한다
- sub브랜치에서 SubTestOne 클래스를 만들어 주고 커밋한다
- 갈래 모양이 생기는것을 확인 할 수 있다
갈래모양이 원래의 브랜치 내용과, 다른 브랜치의 내용이 달라야 갈라지기떄문에 서로 다르게 파일을 만들어주었던 것이다
- 갈래모양 만드는데 까지 성공하였고, main 브랜치에서 sub브랜치를 merge 해보겠다
- 현재 main 브랜치의 상태
- main 브랜치에서 sub 브랜치 병합후
- 잘생성되는 것을 확인 할 수 있다
Rebase
- 대충 의미로 보자면, 어딘 가를 기준으로 새롭게 둥지를 만드는 느낌입니다
- 아까의 첫 시나리오를 기준으로 Rebase를 실행시켜보며 학습해보자
- 이번에는 두가지 경우를 그림으로 살펴볼것이다
- 초록색 master브랜치에서 노란색 sub브랜치를 git rebase시켜보자
- master 브랜치에서, sub 브랜치를 기준으로 rebase 시켰기 때문에, sub 브랜치를 베이스로 커밋 이력이 정렬되는 것을 볼 수 있습니다
코드와 함께 봐보자
- 시나리오는 이전과 동일하게 준비해보았다
- main 브랜치에서 sub 브랜치를 rebase해보도록 하겠다!
- merge했을떄와는 확연한 차이가 보여지는 모습이다
sub브랜치에서 main브랜치를 rebase 해보자
- 그렇다면 이번에는 sub브랜치에서 master브랜치를 rebase시켰을떄의 flow를 확인해봅시다
- 상황은 아까와 동일하다
- 모양은 다름 없지만 색깔이 달라짐을 확인 할 수 있다
rebase 정리
- main브랜치에서 sub브랜치를 rebase 시키면 sub브랜치를 기준으로 이력이 정렬된다
- sub브랜치에서 main브랜치를 rebase 시키면 main브랜치를 기준으로 이력이 정렬된다
- 하지만 주의해야할점이 있다
- 재렬된 커밋이력에 (') 추가가 되면수 해쉬 ID가 변하는것을 볼 수 있다
- 이점이 merge와의 큰차이점이라고 볼 수 있다
- 재정렬되는 commit내역이기 때문에, 재졍렬되는 commit 이력에는 이전과는 다른 새로운 해쉬 ID가 부여됩니다
- 만약 main 브랜치에서 다른 브랜치를 기준으로 rebase를 실행하면, main의 커밋이력이 변할것이다
- 따라서 main에서 sub브랜치를 rebase하는경우는 지양하면 좋다
그렇다면 어느 상황에서 rebase를 사용 할 수 있을까 ?
- 가장 자주 사용되는 경우는 커밋 이력을 깔끔하게 관리하는 경우에 사용할 수 있습니다
- sub브랜치에서 main브랜치를 rebase하던 부분을 되뇌어봅시다
- 다른 브랜치의 커밋 이력위에서 main브랜치를 기준으로 다른 브랜치의 커밋이력이 깔끔하게 재정렬이 되었습니다
- 즉 main브랜치와는 상관없이 다른 브랜치의 이력 위에서 main브랜치를 base로 재정렬 됩니다
한마디로 Fast-Forward-Merge 가 가능하다는뜻
Fast-Forward Merge는 두 브랜치가 직선적인 관계일 때, 병합할 브랜치의 커밋이 단순히 다른 브랜치의 가장 최신 커밋 뒤에 있는 경우에 사용됩니다.
이 경우, 새로운 병합 커밋을 만들지 않고, 단순히 브랜치 포인터만 최신 커밋으로 이동시키는 방식입니다. Fast-Forward Merge는 기존의 커밋 히스토리를 변경하지 않습니다.
흐름을 살펴보자
- main 브랜치로부터 sub브랜치를 생성하고 작업진행
- git checkout sub 이동
- git rebase main
- main브랜치를 기준으로 rebase실행
- main브랜치를 기준으로 sub 브랜치의 이력들이 정리됨
- git checkout main
- rebase해서 이력을 main브랜치를 기준으로 깔끔하게 정리해놓았는데 왜 다시 가는걸까?
- 우리가 한 작업은, sub 브랜치 위에서의 이력을 정리하기 위한 작업입니다
- main브랜치를 기준으로 정렬된 이력을 다시 main브랜치에 반영해야합니다
- git merge sub로 최종내역을 Main브랜치에 반영한다
- 지금까지 작업한 내용을 main브랜치에 반영하여야, 마무리됨
참조 블로그
테러대응전문가