Byeonguk Kim

안녕하세요. 29살의 조금은 늦은 나이로 새롭게 개발자로 시작하는 신입 개발자입니다. 포트폴리오 [https://deaguowl.github.io]

GIT 03. Merge & Rebase

29 Jul 2019 » GIT

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 모두 각자의 가치가 있어서 상황에 따라 다르게 사용해야 한다.

Git Merging 과 Rebase 의 상황별 사용법 – ElegantCoder