[TIL] git rebase

git merge

*git은 commit기준으로 사진처럼 동글뱅이 상태가 생긴다.

* checkout을 기준으로 거기에 다른것을 덧붙이는 것!

git checkout feature 
git merge main

•  feature 가지에 main을 붙이는 것이다.
•  위 명령어를 git merge feature main 이렇게 한줄로도 표현 할 수 있다.

아래 사진은 위 명령어에 대한 결과물이다. 

병합은 어떤 방식으로든 기존 브랜치를 없애지 않기 때문에 비파괴적 운영을 한다. 

 

Git rebase

: feature 브랜치를 main브랜치로 Rebase 할 수 있다.

git checkout feature
git rebase main

=> 이 결과 main 브랜치 끝에 feature 전체가 옯겨가 붙는다. 

그러므로 main 브랜치에서 모든 새 커밋을 통합하는 것이다. 

merge와의 차이점: 원본 브랜치(feature)에서 각 커밋에 대해 새로운 커밋을 만들기 때문에 프로젝트 기록이 재작성된다. 
=> 원본 브랜치가 상한다는 것.

 

그럼에도 reabse를 하는 이유는?

1. 기준 재지정의 주요 이점은 프로젝트 history를 더 명확하게 얻을 수 있다. 위 다이어그램과 같이 완벽한 선형 히스토리를 가진다. 
2. Git merge에서 하는 불필요한 병합 커밋을 제거한다.

-> 하지만 이와같은 rebase는 기준 재지정의 황금률(golden rule)을 따르지 않는 경우 프로젝트 히스토리 재작성은 협업 워크플로우에 치명적일 수 있다. 

그리고 병합 커밋에서 제공하는 context를 손상시킬 수 있다. 

 

1. rebase의 황금률

: rebase를 수행하지 않는 경우

사진 기준으로는 feature 브랜치에 main을 rebase하는 것.

• 이때, rebase는 내 Local repository에서만 이 작업이 이루어진 상태이다. 

[요약]

불필요한 병합 커밋 없이 명확한 선형 히스토리를 선호하는 경우 다른 브랜치에서 변경 사항을 통합할 때 git merge 대신 git rebase를 수행하려고 노력해야 한다.

반면에 프로젝트의 전체 기록을 보존하고 공용 커밋을 다시 쓰는 위험을 피하려면 git merge를 고수할 수 있다. 두 옵션 모두 완전히 유효하지만 적어도 이제 git rebase의 이점을 활용할 수 있다.

 [출처]-https://www.atlassian.com/ko/git/tutorials/merging-vs-rebasing 보고 요약함