JS' 공부흔적
[Git] rebase란? 본문
git rebase는 말그대로 base를 다시(re) 설정하는 것이다. merge와 코드 결과는 같은데, 커밋 히스토리를 단순화하기 위해 사용한다. 예를 들어, master 브랜치에서 experiment 브랜치가 분기되어 나왔다고 했을 때, 아래와 같이 master와 experiment 브랜치 각각 작업한 내용(C3, C4)이 있을 것이다.
merge를 사용한다면?
이때, merge를 사용해 합치게 되면 커밋 히스토리는 아래와 같다.
git checkout master
git merge experiment
즉, C3과 C4의 작업 내용이 합쳐져서 C5에 반영되었다.
rebase를 사용한다면?
그러나 rebase를 사용하게 되면, C4에서 변경된 내용(experiment에서 작업한 내용)을 임시 저장하는 곳이 생긴다. 이를 Patch라고 한다. 아래 사진에서는 C4’인데, 이 Patch를 C3에 적용하는 과정이 rebase이다.
git checkout experiment
git rebase master
그 후에 master 브랜치를 Fast-forward시킨다.
git checkout master
git merge experiment
주의할 점
이미 remote에서 운영하고 있는 브랜치에는 rebase를 적용하면 안 된다. 기존의 커밋 히스토리를 가지고 누군가가 작업하고 있다면 해당 작업자는 rebase한 후의 커밋 히스토리로 인해 코드가 꼬이게 될 수도 있다.
따라서 브랜치를 분기하고 PR 상태에서 rebase를 진행하거나, remote에 push하기 전에 rebase를 먼저 진행해야 한다.
rebase 방법 2가지
rebase 방법에는 2가지가 있다.
- develop 브랜치에서 git pull → 작업한 브랜치로 이동 → git rebase develop
- 또는 작업한 브랜치로 이동 후 git pull origin develop --rebase
위에서 사용했던 rebase 방식은 1번째 방식이다. master 브랜치의 이름이 develop 브랜치로 바뀌었다는 점을 빼곤 동일하다. 이는 PR을 통해 병합하지 않고 local 환경에서 병합을 처리한 후에 remote의 develop 브랜치에 바로 push하는 방식이다. 이 방식을 사용하려면 local의 develop 브랜치가 remote의 develop 브랜치에 맞게 최신화 상태여야 한다. 또한, develop을 Fast-forward 시켜주기 위해 develop으로 이동후 git merge “작업한 브랜치”를 해야한다.
2번째 방식은 아예 remote의 develop 브랜치를 기준으로 rebase하는 방식이다. 이는 Pull Request를 통해 remote 환경에서 병합을 처리할 때 사용한다. 따라서 local의 develop 브랜치가 최신화되어있지 않아도 상관없지만, 추후에 remote의 develop 브랜치의 내용을 반드시 pull 받아야 한다. PR을 통해 병합하는 경우에는 develop을 Fast-forward 시켜줄 필요가 없다.
rebase 시 충돌이 발생하면?
- 충돌 사항 수정으로 해결하고 git add
- git rebase --continue
- 1, 2 반복
정리
git merge와 git rebase의 최종 결과는 같다. git merge가 더 직관적이고 사용하기 쉽지만, remote branch에 커밋 히스토리를 깔끔하게 유지하고 싶다면 rebase를 사용하면 된다.
- merge
- 두 브랜치의 최종 결과를 가지고 병합
- rebase
- 분기한 브랜치에서의 변경 사항을 기존 브랜치에 순서대로 적용하면서 병합