주니어 개발자로 일을 시작하면서 가장 의외였던 장면 중 하나는, 많은 개발자가 git rebase -i 앞에서 유독 몸을 사린다는 사실이었다. 실력이 훨씬 뛰어난 동료들조차 이 명령어만큼은 조심스러워하는 경우가 적지 않다. 그러나 인터랙티브 리베이스가 실제로 하는 일은 놀라울 만큼 평범하다. 텍스트 파일 하나를 열어 줄 뿐이다. 터미널에서 작업하는데 아직 편집기를 손보지 않았다면 git config --global core.editor "편집기"로 익숙한 도구를 지정해 두는 것만으로도 vim에 대한 막연한 공포는 상당 부분 사라진다.
실행이 아니라 계획이다
초보자가 가장 먼저 이해해야 할 점은, 편집기에 뜬 그 화면이 '실행'이 아니라 '계획'이라는 것이다. 리베이스가 시작됐다는 사실 외에 아직 아무 일도 일어나지 않았다. 각 줄은 대상 커밋을 어떻게 다시 재생(replay)할지 지시하는 명령이며, 원하는 대로 섞어 쓸 수 있다. 예컨대 첫 커밋에서 멈춰 메시지를 다시 쓰거나(reword), 디버깅용 WIP 커밋은 drop으로 삭제할 수 있다. 해당 줄을 아예 지워도 결과는 같다. 마음이 바뀌면 git rebase --abort로 언제든 되돌리고, 처음부터 다시 시작하면 된다. 원문의 예시에서는 앞뒤 커밋을 손보는 동안 가운데 두 커밋은 그대로 유지되어, 4개였던 커밋이 3개로 정리된다. 핵심은 이게 전부라는 점이다. 이 동작 하나를 체화하면 리베이스는 삶을 복잡하게 만드는 함정이 아니라 편하게 해 주는 도구가 된다.
작업을 잃기는 생각보다 어렵다
리베이스가 위험하다는 인식의 뿌리에는 '커밋이 사라질 수 있다'는 오해가 있다. 실제로는 작업을 잃기가 상당히 어렵다. 이유는 세 가지다. 첫째, 언제든 git rebase --abort로 빠져나올 수 있고 브랜치는 시작 직전 상태로 정확히 되돌아간다. 둘째, 리베이스는 기존 커밋을 편집하지 않는다. 새 커밋을 만들고 브랜치 포인터를 그쪽으로 옮길 뿐이다. 원래 커밋은 참조가 끊긴 채로도 가비지 컬렉션이 정리하기 전까지 객체 데이터베이스에 그대로 남아 있다. 이 멘탈 모델이 핵심이다. 셋째, reflog가 브랜치가 거쳐 간 모든 위치를 기록한다. 리베이스 이전 항목을 찾아 복원하면 리베이스 전체를 되돌릴 수 있다. 원문 저자도 첫 인턴십 시절 동료의 브랜치 히스토리를 실수로 날린 적이 있는데, 이때 reflog의 존재를 절실히 이해하게 됐다고 털어놓는다. 결국 리베이스를 망쳐도 최악의 현실적 결과는 reflog를 몇 분 뒤적이는 정도다.
reflog조차 부담스럽다면 더 단순한 보험도 있다. 리베이스 전에 현재 상태에 이름을 붙여 두는 것이다. 브랜치를 하나 만들어 pre-rebase 상태를 표시해 두면, 문제가 생겼을 때 git reset --hard로 그 지점에 복귀할 수 있다. 이런 안전망이 늘 존재하기 때문에, 리베이스는 겉보기보다 훨씬 관용적인 작업이다.
충돌은 오히려 다루기 쉽다
사람들이 가장 성가셔하는 지점은 충돌이다. 커밋을 재생하다 보면 순서를 바꾸거나 갱신된 main 위로 리베이스할 때 이전 변경과 충돌이 나기도 한다. 이때 git은 멈춰 서서 해결 방법을 그대로 출력해 준다. 머지 충돌과 똑같이 파일을 수정하고 git add한 뒤 git rebase --continue를 실행하면 된다. 저자는 오히려 인터랙티브 리베이스에서의 충돌이 머지보다 다루기 쉽다고 본다. 브랜치 전체가 아니라 한 번에 커밋 하나만 상대하기 때문이다. 충돌 자체가 git에서 새로운 개념도 아니다.
다만 복구 가능하다는 사실이 부주의의 면허가 되어서는 안 된다. 파괴적일 수 있는 작업일수록 자신이 무엇을 하는지 정확히 이해하고 신중하게 접근해야 한다. 저자가 실무에서 따르는 규칙은 명료하다. 자신의 피처 브랜치는 리뷰 전이든 도중이든 자유롭게 리베이스하고, 그 결과를 원격에 올릴 때는 git push --force-with-lease를 쓴다. 이 옵션은 그사이 다른 사람이 푸시했다면 밀어내기를 거부하므로, 항상 맨 --force보다 우선해야 한다.
결국 이 이야기의 요지는 언제, 왜 리베이스를 써야 하는가가 아니라 그 과정을 신비화하지 말자는 것이다. 깨끗한 브랜치 히스토리는 리베이스가 주는 이점의 작은 조각에 불과하지만, 그것조차 소프트웨어를 대하는 진지함의 척도로 볼 수 있다. 제대로 된 개발자라면 최소한 아주 단순한 인터랙티브 리베이스 정도는 처음부터 끝까지 걸어갈 수 있어야 한다. 특히 이제 막 시작한 주니어라면, 겁먹기보다 일단 한 번 직접 열어 보는 편이 낫다.