리베이스

브랜치를, 곧 본류에서 갈라져 나온 작업 줄기를 따서 사흘 동안 기능을 만들면 그사이 본류도 앞으로 갑니다. 동료 넷이 각자 자기 것을 합쳐 넣었기 때문입니다.

머지로 합치면 합쳤다는 사실 자체가 기록으로 남습니다. 한두 번이면 읽을 만한데 사람이 여덟 명이 되면 이력이 그물처럼 얽힙니다. 장애가 나서 원인을 거슬러 찾을 때 이 모양이 걸립니다. 지난 2주 기록에 합침 기록이 마흔 개 끼어 있으면 어느 변경이 언제 들어왔는지 순서대로 읽을 수가 없습니다.

기록 자체가 지저분한 문제도 있었습니다. 기능 하나를 만드는 동안 남긴 커밋이 오타 수정, 다시 수정, 이번엔 진짜 수정 세 개로 남습니다. 본인에게는 작업 일지지만 나중에 그 코드를 들여다보는 사람에게는 잡음입니다.

리베이스는 이 둘을 함께 다룹니다. 합치기 전에 내 커밋을 떼어 본류의 최신 끝에 다시 얹어, 처음부터 최신 위에서 작업한 것처럼 만듭니다. 기차 차량을 떼어 다른 기관차 뒤에 다시 붙이는 일과 비슷합니다. 실려 있는 짐은 그대로인데 어느 기관차 뒤에 서 있는지가 바뀝니다.

본류의 최신 상태를 받아 온 뒤 내 커밋을 그 위로 하나씩 다시 얹습니다. Git에서는 명령 한 줄이지만 안에서 벌어지는 일은 다섯 단계입니다.

1. 본류를 최신으로 받아 옵니다. 리베이스가 얹어 놓을 기준이 이 시점이 됩니다.
2. 내 브랜치에서 리베이스를 시작합니다. 내 커밋 다섯 개를 잠시 떼어 두고, 본류의 끝에서부터 하나씩 다시 얹습니다.
3. 충돌이 나면 그 커밋에서 멈춥니다. 같은 파일의 같은 줄을 나와 동료가 다르게 고친 경우입니다. 머지는 합칠 때 한 번만 부딪히는데, 리베이스는 커밋을 하나씩 얹으므로 같은 자리에서 여러 번 부딪힐 수 있습니다. 해결하고 계속을 지시하면 다음 커밋으로 넘어갑니다.
4. 필요하면 커밋을 정리합니다. 대화형으로 실행하면 커밋 세 개를 하나로 합치거나 메시지를 고칠 수 있습니다. 앞에서 말한 오타 수정 세 개가 여기서 한 개가 됩니다.
5. 올립니다. 이미 원격에 올려 둔 브랜치를 리베이스하면 커밋의 식별자가 새로 만들어지기 때문에 그냥 올라가지 않고 강제로 올려야 합니다. 이 자리가 사고가 나는 지점입니다.

그래서 순서를 정해 두는 편이 안전합니다. 풀 리퀘스트를 올리기 전에 정리하고, 올린 뒤에는 리베이스를 하지 않고 커밋을 더해 나갑니다. 리뷰어가 이미 읽은 줄이 통째로 바뀌면 코드 리뷰에 남긴 의견이 어느 줄에 달린 것인지 알 수 없게 됩니다.

맞는 자리는 셋입니다. 나만 쓰는 브랜치를 정리할 때, 풀 리퀘스트를 올리기 전에 커밋을 다듬을 때, 그리고 본류가 한참 앞서 간 상태에서 내 작업이 최신 위에서도 돌아가는지 확인할 때입니다.

한계는 넷입니다.

1. 여러 사람이 공유하는 브랜치와 본류에는 쓰지 않습니다. 커밋이 새로 만들어지므로 다른 사람이 이미 받아 둔 사본과 갈라집니다. 그 사람이 다시 받아 오면 같은 변경이 두 벌 들어오거나 자기 작업이 사라집니다.
2. 충돌이 여러 번 반복됩니다. 커밋 열 개를 얹는 동안 같은 파일에서 네 번 멈추는 일이 생깁니다. 브랜치를 오래 묵힐수록 심해집니다.
3. 합쳤다는 사실이 기록에 남지 않습니다. 이력은 곧게 펴지는데, 어느 작업 묶음이 언제 한 덩어리로 들어왔는지는 흐려집니다.
4. 되돌리기가 번거롭습니다. 머지는 합침 기록 하나를 되돌리면 그 묶음 전체가 빠지지만, 리베이스로 들어온 커밋은 개별 커밋으로 흩어져 있어 하나씩 골라야 합니다.

팀이 어느 쪽을 쓸지 미리 정해 두는 것이 이 용어를 다루는 실제 작업입니다. 트렁크 기반 개발처럼 브랜치를 이틀 이상 두지 않는 방식에서는 리베이스 쪽이 자연스럽고, 기능 브랜치를 오래 유지하는 방식에서는 머지 기록이 추적에 쓰입니다. 섞어 쓰면 이력을 읽는 규칙이 사람마다 달라집니다.

"올리기 전에 리베이스해서 커밋 합쳐 주세요. 오타 수정이 세 개 있어요."

기록을 읽을 사람을 위해 다듬어 달라는 요청입니다.

"본류가 많이 앞서 갔는데 리베이스하고 테스트 한 번 돌려 보죠."

최신 상태 위에서 문제가 없는지 미리 확인하자는 제안입니다.

"그 브랜치는 저도 받아서 쓰고 있어요. 리베이스하면 제 쪽이 어긋납니다."

공유된 브랜치에서는 쓰지 않는다는 규칙을 확인하는 말입니다.

페이지덱에서는 태오가 풀 리퀘스트를 올리기 전에 커밋을 정리합니다. 작업 중에는 생각나는 대로 기록을 남기고, 올리기 직전에 의미 있는 단위 두세 개로 합쳐 메시지를 다시 씁니다. 올린 뒤에는 손대지 않고 리뷰 의견을 새 커밋으로 반영합니다.

규칙을 세운 계기도 있었습니다. 둘이 함께 쓰던 브랜치를 한쪽이 리베이스해 강제로 올렸고, 다른 쪽이 그것을 받아 오면서 반나절치 작업이 사라졌습니다. 그 뒤로 여럿이 붙은 브랜치에는 쓰지 않기로 적어 두었습니다.

리베이스가 머지보다 나은 방법이라고 보는 경우가 가장 많습니다. 이력이 깔끔해진다는 설명을 먼저 듣게 되니 그렇게 읽힙니다. 하지만 둘은 같은 일을 하고 결과로 남는 코드도 같습니다. 다른 것은 기록의 모양뿐입니다. 고를 기준은 좋고 나쁨이 아니라 그 기록을 무엇에 쓰는지입니다. 원인을 거슬러 찾는 데 주로 쓰면 한 줄로 펴진 쪽이 편하고, 어떤 기능이 언제 한 덩어리로 들어왔는지를 봐야 하면 합침 기록이 남는 쪽이 낫습니다.

기록을 지운다고 보거나 반대로 안전한 작업이라고 보는 것도 흔합니다. 두 오해는 같은 자리에서 나옵니다. 리베이스는 기존 커밋을 옮기는 것이 아니라 같은 내용으로 새 커밋을 만들어 붙입니다. 내용은 남지만 식별자가 바뀝니다. 그래서 혼자 쓰는 브랜치에서는 잃는 것이 없고, 공유된 브랜치에서는 남이 들고 있는 사본과 갈라집니다. 안전한지 위험한지는 작업 자체가 아니라 그 브랜치를 몇 명이 보고 있는지로 정해집니다.