GIT

깃공부4: 깃 리베이스(Rebase)

이소금 2019. 9. 15. 22:17
반응형

열심히 번역본을 적어놨더니 웬걸 한글 버전이 있네요.. 원래 삽질은 개발자의 기본 소양 아니겠습니까 쿨하게 인정하고 공부 해보겠습니다!

 

우선 이 웹사이트에 따르면 리베이스는 여기저기 브랜치에 흩어져있는 커밋들을 하나의 브랜치에 정렬시킬 수 있다는 말인데..

그럼 리베이스는 커밋의 병합 개념일까요 오버라이딩의 개념일까요?

결국 리베이스를 하면 다른 브랜치와 마스터가 결국 하나의 커밋을 가리키게 되는데 오버라이딩에 가까울 것 같습니다.

그러면 리베이스때는 충돌이 나지 않을까요?

 

그래서 구글링을 해봤습니다.

 

머지와 리베이스는 순전히 개발자의 취향대로 선택된다고 합니다. 위 그림을 참고하시면,

머지는 병합 후에도 다른 브랜치의 커밋을 모두 보존합니다. 그러나 단점은, 개발자가 많아지거나 브랜치가 많아지면 커밋의 히스토리를 볼때 매번 선택의 기로에 설 수 있습니다. 매번 이렇게 선택하게 되면 더욱 복잡해지고 히스토리 찾기가 어려워집니다.

리베이스는 이러한 머지의 단점을 보완하기 위해 매번 커밋할 때 덮어쓰는 개념이 되어 하나의 커밋라인이 완성됩니다. 위 사진처럼 커밋라인이 한줄이라고 해서 모두 마스터에서 작업을 하는 것이 아닙니다. 브랜치의 개념도 있으나 브랜치에서 진행한 커밋을 매번 마스터에 오버라이딩 하는 형식이 됩니다. 그러나 이 방식은 머지보다 훨씬 충돌 해결이 복잡하며(리베이스 순서대로 충돌 해결 필요), 개발자들끼리도 추가되는 기능에 계속 업데이트가 되어야 합니다.

이러한 특징이 있으니 사용하고 싶은 방향으로 사용하시면 되겠습니다.

시간나면 소스트리 웹사이트 한번 참고해보세요! 저도 시간나면 더욱 자세히 기술하겠습니다 :)

https://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

 

Merge or Rebase? | SourceTree Blog

By Steve on August 21, 2012 As you’re no doubt aware, Git and Mercurial are great at re-integrating divergent lines of development through merging. They have to be, since their design strongly encourages developers to commit changes in parallel in their ow

blog.sourcetreeapp.com

 

반응형