git rebase

Rebase

base에서 새로 브랜치를 생성해서 작업을 하면 f1, f2 커밋이 생겼다고 할 때, master은 새로운 커밋을 만들어 낸다고 가정하자.

rebase를 적용하게 되면,
아래 그림처럼 feature의 base가 m2로 재설정(Rebase)을 하는 것이다.
즉 re-base branch의 base를 다시 설정한다는 의미이다.

내 브랜치에서 작업 한 후 마스터로 checkout한다.

git checkout master

그리고 rebase하기 전에 pull하는 습관을 들이자.

git pull origin master

git rebase -i master feature/modeling

vim edit 창이 열리면,
pick은 처음 꺼만 놔두고 나머지는 squash로 바꿔서 모든 commit 내용을 합칠 수 있다.
그러고, tig로 들어가보면 커밋이 한개로 바뀐 것을 볼 수 있다.

master와 branch가 conflict가 생기면 rebase가 중지되고 직접 conflict를 해소해야한다. 해소 한 후 다시 진행되도록 아래 코드를 입력한다.

git rebase --continue

강제로 밀어넣기

만약 내가 남긴 pull reqeust를 했는데 이미 다른 개발자가 merge가 되어버리면 rebase가 안되므로

git push origin feature/modeling -f

이렇게 강제로 해버려야하는데 신중히 사용해야한다.

Rebase vs. Merge

히스토리를 보는 관점 중에 하나는 작업한 내용의 기록으로 보는 것이 있다. 작업 내용을 기록한 문서이고, 각 기록은 각각 의미를 가지며, 변경할 수 없다. 이런 관점에서 커밋 히스토리를 변경한다는 것은 역사를 부정하는 꼴이 된다. 언제 무슨 일이 있었는지 기록에 대해 거짓말 을 하게 되는 것이다. 이렇게 했을 때 지저분하게 수많은 Merge 커밋이 히스토리에 남게 되면 문제가 없을까? 역사는 후세를 위해 기록하고 보존해야 한다.

히스토리를 프로젝트가 어떻게 진행되었나에 대한 이야기로도 볼 수 있다. 소프트웨어를 주의 깊게 편집하는 방법에 메뉴얼이나 세세한 작업내용을 초벌부터 공개하고 싶지 않을 수 있다. 나중에 다른 사람에게 들려주기 좋도록 Rebase 나 filter-branch 같은 도구로 프로젝트의 진행 이야기를 다듬으면 좋다.

Merge 나 Rebase 중 무엇이 나으냐는 질문은 다시 생각해봐도 답이 그리 간단치 않다. Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을 수 있지만, 모든 팀과 모든 이가 처한 상황은 모두 다르다. 예제를 통해 Merge 나 Rebase가 무엇이고 어떤 의미인지 배웠다. 이 둘을 어떻게 쓸지는 각자의 상황과 각자의 판단에 달렸다.

일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.