🧐rebase
rebase는 사전 의미와 같이 base를 재설정한다는 의미이다.
여기서 말하는 base는 branch의 base를 의미한다. branch는 base 지점을 가지고 있어 base에서부터 코드를 수정한다.
git history를 살펴보면 branch의 base가 어디 있는지 확인할 수 있다.
깃에서 작업을 위해 master에서 새로운 branch를 따서 작업을 할 때, 협업 상황에서는 다른 사람이 master에 commit하는 상황이 발생하게 된다.
그런 경우 현재 내가 작업하고 있는 master는 현재의 master와는 다른 상황이 발생하게 된다. 이 경우 rebase를 통해 이때까지 commit된 상태의 최상단으로 현재 내가 작업하고 있는 master를 옮길수 있다.
merge 와 rebase
merge 와 rebase 의 경우 모두 git의 코드를 합치는 방법이지만 서로 추구하는 방향에 따라서 다르게 사용한다.
Merge는 branch를 통합하는 것이고, Rebase는 branch의 base를 옮긴다는 개념이라고 이해하면 되겠다.
그래서 둘 중에 하나만 쓰는 것이 아니라 두가지가 존재한다.
- Merge만 사용한다.
- Rebase와 Merge를 사용한다.
merge 장점
- 이해하기 쉽다.
- 원래 브랜치의 컨텍스트를 유지한다.
- 브랜치 별로 커밋을 분리해서 유지해준다.
- 원래 브랜치의 커밋들은 변경되지 않고 계속 유지되어 다른 개발자들의 작업과 공유대는 것에 대해 신경 쓸 필요가 없다.
merge 단점
- 모든 사람들이 같은 브랜치에서 작업하기 때문에 머지해야 할 때는 merge가 커밋 히스토리상으로 전혀 유용하지 않고 어지럽기만 하다.
rebase 장점
- 단순한 히스토리
- 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법
rebase 단점
- 충돌상황에서 다소 복잡하다. 커밋 순서대로 rebase를 하는데, 각 커밋마다 충돌해소를 순서대로 해주어야 한다. SourceTree가 가이드하기는 하지만, 역시 복잡한 것은 사실이다.
- 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시 쓰는 것에 부작용이 발생한다. Mercurial에서는 간단히 푸시를 할 수 없다. git에서는 push할 수 있으나 나 혼자 쓰는 리모트 브랜치에서만 가능하다. 만약 다른 사람이 그 브랜치를 체크아웃 받은 후 내가 리베이스 한다면 꽤 혼란스럽게 될 것이다.
