안녕하세요!
Git Reabse 에 관한 포스팅입니다.
먼저 Rebase의 특징입니다.
Rebase
$ git rebase [newbase]
그럼 두 개의 브랜치로 나뉘어진 커밋 히스토리가 있는 상황에서 Merge
와 Rebase
를 비교해 본 후 Rebase
에 대해 좀 더 자세히 알아보겠습니다.
이 두 브랜치를 합치는 가장 쉬운 방법은 merge 명령을 이용해 3-way Merge로 새로운 커밋을 만들어내는 것입니다.
이 때 내부적으로 공통조상인 C2를 이용하게 됩니다.
두 브랜치가 나뉘어 있는 아까와 같은 상황에서 시작합니다.
experiment
브랜치로 이동해 master를 base삼아 Rebase 하겠다는 의미입니다.
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
그러면 내부에서는 master가 base가 되고, C3과 C4의 차이를 임시 저장하는 공간에 저장합니다. 이 임시저장 공간을 Patch
라고 합니다.
그리고 base
가 되는 master
에 Patch
들이 적용됩니다. (이렇게 생각하는 편이 개인적으로 이해하기 좋다고 생각해 적었습니다.)
다시 정리하겠습니다.
diff
를 차례대로 만들어 Patch
에 저장아까 Merge와 다른점이 눈에 확연히 보입니다!
커밋들이 여러갈래로 있었던 Merge와 다르게 커밋 히스토리가 한 줄로 깔끔하게 정렬된 것을 볼 수 있습니다.
이제 마지막으로 master브랜치를 Fast-forward
시킵니다.
$ git checkout master
$ git merge experiment
Merge의 결과에서의 C5
가 위 사진의 C4'
는 내용이 같습니다.
결과적으로 봤을 때는 서로 다를게 없습니다. 하지만 Rebase가 좀 더 깨끗한 히스토리를 만듭니다.
Rebase는 그래서 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용합니다.
또 다른 차이점은 Rebase는 브랜치의 변경사항 Patch를 이용한다는 점, Merge의 경우는 두 브랜치의 최종 결과만을 가지고 합친다는 점입니다.
아래의 상황을 가정해보겠습니다.
이렇게 세 브랜치가 있습니다.
그런데 client 브랜치를 급하게 릴리즈버전에 업데이트 한다고 할 때, C8
과 C9
는 Merge되어야 합니다.
이런 경우 server브랜치와 server커밋 히스토리에 영향을 주지않고 Rebase
할 수 있는 옵션이 있습니다.
$ git rebase --onto master server client
git rebase --onto [newbase] [upstream] [branch]
의 형식입니다.
master
C3
client
이 세개를 이용한 명령입니다.
이번에도 역시 Fast-forward
시켜줍니다.
$ git checkout master
$ git merge client
성공적으로 client브랜치의 수정사항을 master브랜치에 적용했습니다.
마지막으로 serve도 포함시킵니다.
$ git rebase master server
$ git checkout master
$ git merge server
필요없어진 브랜치 client
와 server
를 삭제합니다.
*커밋 히스토리가 직렬로 깔끔하게 정리된 걸 볼 수 있습니다 *
협업을 하고있고 언제 사용할지 모르겠다면 push하기전에만 rebase를 사용하세요!
git pull
명령을 실행할 때 기본적으로 --rebase
옵션이 적용되도록 pull.rebase 설정을 추가할 수 있습니다. git config --global pull.rebase true
명령으로 추가합니다.여기까지 입니다.
시리즈에 포스팅한 내용들은 Github을 사용하기 전에 알면 좋을 Git에 대한 내용 정리였습니다.
다음 포스팅은 Github에서의 협업 워크플로를 위해 사용하는 Pull Request
에 대해 알아보게습니다.
감사합니다. 잘 읽고 갑니다~!