이번에는 Git Rebase와 관련하여 글을 하나 작성해 보려고 한다.
<목차>
1. Git Rebase의 개념
2. 사용 방법
1. Git Rebase의 개념
Git Rebase 개념을 설명하기에 앞서 간단하게 Git에 대해서 설명하고 넘어가자면, Git은 여러명의 프로그래머가 협업을 할 경우에 프로젝트를 관리하고 함께 진행하기 위한 프로그램이다. 서로 각자의 업무를 하고 마스터 브런치에 자신이 한 업무를 보내서 합치는 방식이다. 이런 기능을 깃에서는 Merge(병합)한다고 표현한다.
깃 리베이스 기능은 깃 머지(merge)와 비슷한 부분이 있다. 깃 머지를 하게 되면 위에서 서술한 것과 같이 내가 작성한 코드가 마스터 브런치에 합쳐져서 다른 사람이 작성한 코드와 합쳐져 하나의 프로젝트가 완성되게 되는데, 머지를 사용하게 되면 업무 이력을 관리하는 데 있어서 약간의 불편함이 있을 수 있다. 이를 해결하기 위해 사용하는 것이 깃 리베이스 인데 먼저 깃 머지를 사용했을 때의 불편함을 알아보자.
위의 사진을 참고해서 설명하려고 한다. 만약 sign-up 기능 구현이 먼저 끝나게 되서 마스터 브런치에 머지하게 되면 머지에 대한 commit message가 저절로 생기게 된다. sign-in 기능 구현을 하던 프로그래머는 sign-up 기능과 관련된 코드를 마스터 브런치로 부터 pull을 해서 가져올 수 있는데, 이때 머지에 대한 commit message까지 가져오게 된다.
즉, 불필요한 머지 commit message가 계속 생기게 되며, 이는 많은 프로그래머가 협업을 할 경우에는 커밋 메세지를 직관적으로 알아보기 힘들게 만들수 있으며, 이에 따라 관리가 어려워 질 수도 있다.
이에 대한 해결책으로 깃 리베이스 기능이 있는데, 설명하자면 아래와 같다.
위의 첫 번째 사진과 같은 상태로 작업이 진행중이었다고 했을 때, sign-up 기능 구현이 먼저 완료되어 마스터 브런치에 리베이스(머지)되었다. 이 때 sign-in 기능 구현을 하던 프로그래머는 본인의 마스터 브런치(로컬 마스터 브런치)로 이동하여 sign-up 기능 구현이 완료된 코드를 pull 한다.
그 다음, 본인이 작업하던 브런치로 돌아가 git rebase를 해주게 되면, 두 번째 사진과 같이 본인이 한 작업이 마스터 브런치의 마지막 커밋 뒤로 밀리게 된다. 즉, 커밋의 순서가 중간중간 겹치는 것이 아니고 하나의 기능에 해당하는 커밋들이 일렬로 정렬되는 효과를 가질 수 있다. 거기에 더해서 깃 머지를 사용했을 때 생성되는 커밋 메세지가 따로 생성되지 않아서 커밋 관리가 좀 더 직관적이고 편하다.
사용 방법에 대해서는 다음 글에서 상세히 다뤄보려고 한다.
그럼 이만...
