영화에서 등장하는 '만약에' 타임라인을 떠올려 보세요. 어떤 캐릭터가 평행 우주를 열고 그 안에서 파란만장한 사건을 겪는 동안, 현실 세계는 아무 일도 없었다는 듯 그대로 돌아가요. 브랜치가 바로 그거예요.
지금 잘 돌아가는 프로젝트가 있다고 해 볼게요. 서비스가 운영 중이고 사람들이 쓰고 있어요. 그런데 뭔가 위험한 시도를 해보고 싶어요. 결제 흐름을 뜯어고치거나, 홈페이지를 전면 재설계하거나. 무서운 건 아이디어 자체가 아니에요. 그 아이디어가 이미 잘 돌아가는 것을 망가뜨릴 수도 있다는 점이죠.
그래서 원본에는 손대지 않아요. 복사본을 따로 떼어내요.
그 복사본이 브랜치예요. 모든 것을 통째로 복제해 옆으로 떼어낸 공간으로, 거기서는 마음껏 실험해도 돼요. 원본은 건드리지 않은 채 안전하게 있고, 그 사이 마음껏 놀 수 있어요. 원본에는 거의 항상 이름이 붙어 있고, 그 이름은 main이에요. (오래된 프로젝트에서는 'master'도 볼 수 있어요. 같은 뜻이에요.) main은 현실이에요. 브랜치는 샌드박스예요.
평범한 순서로 보면 이렇게 돼요.
현재 main, 즉 작동 중인 버전에 있어요.
브랜치를 만들어요. 이제 같은 내용을 가진 복사본이 별도의 이름으로 생겼어요.
브랜치에서 마음대로 해요. 망가뜨리고, 고치고, 말도 안 되는 아이디어도 시도해 봐요.
main은 단 하나도 변하지 않았어요. 마치 아무 일도 없었다는 듯 그대로 작동하고 있어요.
브랜치 이름은 만들고 있는 작업 이름을 따서 지어요. 기능 하나를 추가하기 위해 만든 브랜치는 피처 브랜치(feature branch)라고 부르고, 히스토리가 자연스럽게 읽히도록 작업 이름을 붙여요.
add-checkout-button은 한 브랜치에fix-coupon-bug는 다른 브랜치에redesign-homepage는 또 다른 브랜치에
세 가지 위험한 실험이 세 개의 분리된 우주에서 각각 진행되고, 서로도 건드리지 않고 main도 건드리지 않아요.
그다음은 판정이에요. 브랜치에서 작업이 끝나고 테스트를 통과하면, main으로 머지(merge)해요. 머지는 '이 실험을 현실에 반영한다'는 의미예요. 사이드 퀘스트였던 변경이 실제 서비스에 합쳐지는 순간이에요.
만약 실험이 완전히 실패했다면? 브랜치를 삭제하고 떠나면 돼요. main은 그 브랜치가 존재했는지도 몰라요. 정리할 것도, '피해를 되돌릴' 것도, 흔적도 없어요. 평행 우주 자체가 그냥 사라지는 거예요. 브랜치가 강력하게 느껴지는 이유가 바로 이거예요. 최악의 결과가 '브랜치를 버린다'이지, '라이브 서비스를 망가뜨렸다'가 아니에요.
팀 전체가 하나의 프로젝트를 서로 방해하지 않고 함께 작업할 수 있는 것도 같은 원리예요. 모두가 자신의 브랜치, 자신의 우주에서 작업하고, 준비가 되면 각자 main에 합쳐요. 같은 라이브 파일을 동시에 편집하며 서로 발을 밟는 일이 없어요.
이제 들으면 당황할 수 있는 단어 하나를 짚어 둘게요. 충돌(conflict). 두 사람 또는 두 브랜치가 같은 줄을 동시에 수정하면, 머지할 때 Git이 어느 버전을 쓸지 판단할 수 없어요. 그래서 잠시 멈추고 물어봐요. 이것이 머지 충돌(merge conflict)이에요. 경보가 울리는 것처럼 들리지만, 실은 Git이 정중하게 묻는 것에 불과해요.
"두 사람 모두 이 줄을 바꿨어. 어느 걸 쓸 거야?"
선택하고, 저장하고, 계속 진행하면 돼요. 그게 전부예요.
브랜치를 다시 합치는 공식적이고 깔끔한 방법도 있어요. 특히 누군가 먼저 검토해야 할 때 써요. 그것을 풀 리퀘스트(pull request)라고 해요.
브랜치에서 실험하고, main은 안전하게 지켜요.