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