최종본, 진짜 최종본 — 깃은 무엇을 기억할까

원고를 고친 뒤 이름을 최종본으로 저장한다. 다시 고치면 진짜 최종본이 되고, 다음에는 최종본 수정이 된다. 두 사람이 각자 받은 파일을 고치기 시작하면 어떤 문장이 최신인지도 헷갈린다. 소프트웨어를 만드는 사람들도 비슷한 문제를 훨씬 큰 규모로 겪는다.

깃은 이런 작업의 상태와 이력을 관리하는 도구다. 명령어를 배우지 않아도 왜 필요한지는 이해할 수 있다. 무엇을 바꾸었는지 기억하고 서로 다른 작업을 비교하며 다시 이어 붙일 수 있어야 여러 사람이 하나의 결과물을 만들 수 있기 때문이다.

01. 파일 이름에 역사를 맡기지 않으려면

파일 이름을 바꾸어 보관하면 몇 개의 과거 상태는 남길 수 있다. 하지만 수백 개의 파일이 함께 바뀌는 프로젝트라면 이야기의 단위가 달라진다. 어느 문서와 어느 이미지가 같은 시점의 한 묶음인지도 알아야 한다.

깃에서 작업 상태를 기록하는 커밋은 이런 묶음을 남기는 행위다. 《Pro Git》은 이를 프로젝트의 스냅숏이라는 말로 설명한다. 실제 화면 사진을 찍는 것이 아니라 그때의 파일 상태를 가리킨다. 바뀌지 않은 파일까지 매번 새로 통째로 중복 저장한다는 뜻도 아니다.

02. 시작에는 협업 도구의 문제가 있었다

깃의 역사 안내는 리눅스 커널 개발에서 출발한 배경을 설명한다. 리눅스 개발자들은 2002년부터 비트키퍼라는 도구를 사용했지만, 2005년 개발 공동체와 그 회사의 관계가 틀어지고 무료 사용이 중단되었다.

리누스 토르발스 등을 중심으로 새 도구를 만들게 된 계기였다. 빠르게 작동하고, 큰 프로젝트를 다루며, 여러 갈래의 작업을 지원하고, 한곳에만 의존하지 않는 방식이 목표에 들어갔다. 처음부터 모든 사람의 일상 파일을 위한 서비스로 기획되었다기보다 큰 공동 개발의 필요에서 나온 것이다.

03. 과거의 어느 지점인지 알아야 한다

원고에서 문장 하나가 바뀌었다면 이전과 이후를 비교해 볼 수 있어야 한다. 작업의 기록에는 내용뿐 아니라 변경을 설명하는 말도 중요하다. 왜 고쳤는지 남겨 두면 나중의 독자가 그때의 의도를 짐작하는 데 도움이 된다.

컴퓨터가 변경 자체를 기억하는 것과 사람이 변경을 이해하는 것은 다른 문제다. 기록을 남겼다는 사실만으로 좋은 설명이 생기지는 않는다. 어느 문장을 바꾸었는지는 보여도 왜 사실관계를 수정했는지 쓰지 않으면 다시 자료를 찾아야 할 수 있다. 도구의 기억 위에 사람의 설명이 필요하다.

04. 다른 가능성을 따로 시험한다

한 원고의 도입부를 두 가지로 고쳐 보고 싶다고 해 보자. 지금의 원고를 바로 덮어쓰지 않고 다른 흐름에서 실험할 수 있다면 마음이 가벼워진다. 깃의 브랜치는 여러 갈래의 작업을 다룰 수 있게 하는 방식이다.

이것은 단순히 폴더를 하나 더 복사해 두는 것과 작동 원리가 같지는 않지만, 독자가 목적을 이해하기에는 도움이 되는 비유다. 한 갈래에서는 표현을 고치고 다른 갈래에서는 자료를 보완한 뒤 결과를 비교할 수 있다. 선택하지 않은 실험과 현재 사용할 결과를 구별하기 쉬워진다.

05. 자동으로 합칠 수 없는 순간도 있다

두 사람이 서로 다른 문단을 고쳤다면 변경을 함께 반영하기가 비교적 쉽다. 그런데 같은 문장을 서로 다르게 고치면 어느 쪽이 맞는지 사람이 결정해야 할 수 있다. 이런 충돌을 발견하는 일과 내용의 정답을 판단하는 일은 다르다.

깃은 역사적 사실을 아는 편집자가 아니다. 문장이 더 정확한지, 작품 제목을 잘못 적었는지까지 스스로 보장하지 않는다. 변경을 비교하고 선택할 자리를 제공할 뿐이다. 협업의 수고를 줄이면서도 중요한 판단은 사람과 편집 과정에 남는다.

06. 인터넷이 없어도 할 수 있는 일

분산된 방식이라는 말은 각 작업 공간이 상당한 이력을 함께 가질 수 있다는 뜻이다. 《Pro Git》은 많은 작업을 자기 컴퓨터의 자료로 처리할 수 있다고 설명한다. 연결이 끊겨도 변경을 기록하고 과거 상태를 살펴보는 일이 가능하다.

다만 자기 컴퓨터에 기록한 내용이 자동으로 다른 사람에게 전달되는 것은 아니다. 함께 쓰는 저장소와 내용을 주고받는 과정이 별도로 필요하다. 개인의 기록과 공동 공간의 반영을 구별해야 한다. 내 책상 위에서 원고를 고친 것과 편집부 전체에 새 원고를 전달한 것이 다른 것과 비슷하다.

07. 깃과 GitHub는 같은 것일까

깃은 버전 관리를 하는 도구이고, GitHub는 깃 저장소를 온라인에서 보관하고 협업할 수 있게 하는 서비스다. 이름이 비슷하고 함께 많이 쓰이지만 하나가 곧 다른 하나는 아니다. 깃을 쓰는 모든 일이 반드시 GitHub를 거쳐야 하는 것도 아니다.

둘을 구별하면 온라인 서비스가 제공하는 검토와 게시 기능도 더 잘 이해할 수 있다. 파일의 이력을 남기는 일, 동료에게 수정을 보여 주는 일, 실제 홈페이지에 반영하는 일은 연결될 수 있지만 각각의 단계다. 저장소에 원고가 있다고 곧바로 독자에게 게시된 것은 아니다.

08. 기억을 맡겨도 편집은 남는다

기록하지 않은 변경은 잃을 수 있고, 기록한 내용을 지우거나 잘못 다루는 일도 가능하다. 버전 관리가 모든 사고를 막는 마법의 보험은 아니다. 중요한 기록을 남기고 다른 보관처와 공유하는 습관까지 있어야 그 장점이 살아난다.

깃의 이야기는 결국 함께 고치는 일의 역사다. 파일 이름 끝에 최종이라는 말을 몇 번 붙이는 대신 어떤 상태에서 무엇이 달라졌는지를 이어 남긴다. 덕분에 우리는 과거를 모두 외우는 데 쓰던 힘을 지금의 문장을 더 좋게 만드는 데 쓸 수 있다.