Rebase

Rebase란?

Git에서 브랜치를 다른 브랜치에 병합하는 방법은 "Merge"이다.
Git에서는 다른 방법으로 브랜치를 병합하는 방법을 제공하는데, 이것이 바로 "Rebase"이다.

Rebase는 커밋의 베이스를 띄어 다른 커밋(브랜치) 뒤로 붙이는 것을 의미한다.

이 Rebase 작업은 원래 병합 커밋(Merge Commit)으로 Merge 해야 하는 브랜치를 빨리 감기 병합(Fast-forward Commit) 방식으로 병합시켜 커밋의 이력을 조작함으로써 조금 더 깔끔한 Git Log를 남길 수 있다.

조금 어려운데 그림으로 알아보자.

커밋들이 위와 같이 병합된다고 가정하자.
이런 방식으로 병합할 경우 "6번 커밋"이라는, 어떻게 보면 큰 의미 없이 오직 "Merge를 위한 커밋"이 새로 생성된다.

이러한 Merge를 위한 커밋을 Git Log에 남기고 싶지 않아 아래와 같은 방식으로 병합을 실시할 수 있다.

커밋3과 커밋4를 가지고 있는 브랜치를 뚝 띄어 커밋5 뒤에 붙임으로써 마치 커밋5가 존재하는 브랜치에서 작업한 것처럼 이력을 조작하는 것이다.
이러한 방식을 바로 "Rebase"라고 한다.

Rebase는 병합 커밋(Merge Commit)과 달리 Merge를 위한 커밋을 생성하지 않고 존재하는 커밋에 다른 브랜치들의 커밋을 덮어쓰는 형식으로 Git Log가 깔끔하게 남는다는 장점이 있다.

Rebase에 대한 개인적인 고찰

과연 "Git Log를 깔끔하게 남긴다"라는 것이 장점일까?

개인적으로는 "A와 B의 작업물을 병합(Merge) 했다"라는 것도 훌륭한 기록이라고 생각한다.
이 병합이라는 기록은 대충 생각해도 아래와 같은 의미를 가질 수 있을 것 같다.

• 병합 커밋이 생성되었을 때 작업이 완료되어 실제 사용할 브랜치에 작업물이 병합되었다.
• 만약 병합한 작업물에 문제가 있을 경우 누구의 작업물에서 발생한 문제인지 파악할 기준이 될 수 있다.
• A의 작업물(혹은 B의 작업물) 만 가지고 오고 싶을 때 어떤 커밋을 가져와야 할지 명확하다.

Git 명령어를 배우다 보면 알겠지만 Git Log를 깔끔하게 변경하는 명령어에는 무조건 -f, 혹은 --force 옵션이 들어간다.
즉, Git은 Git Log를 변경할 때 명령어를 통해 "강제로" 명령을 수행시켜야 한다는 것이다.
그리고 필자는 "시스템 상에서 막아둔 것을 강제로 수행시킨다"라는 것이 사용을 권장하는 것은 아니라고 생각한다.

https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

위 사이트에선 Git Rebase 사용을 멈춰야 하는 이유를 설명한다.
물론 나의 생각이 무조건 옳다는 것도 아니고 위 글을 쓴 사람의 의견이 100% 옳다는 것도 아니다.
하지만 읽다 보면 꽤나 합리적인 의견이기도 하고, git rebase의 위험성에 비해 장점이 크지 않다고 생각해 아마 필자는 사용하지 않을 것 같다.

그러한 의미로 CLI 명령어도 정리하지 않을 것이다. 절대 귀찮아서 정리하지 않은 것이 아니다!