Git

같은 파일을 여럿이 고치는 순간부터 문제가 생깁니다. 오래된 해법은 파일 이름에 날짜와 이름을 붙이는 것이었습니다. 한 폴더에 기획서_0312.docx, 기획서_0312_수정.docx, 기획서_최종_민서.docx 가 나란히 쌓이면 어느 것이 최신인지는 파일을 다 열어 보기 전에는 알 수 없습니다.

코드에서는 이 방식이 더 빨리 무너집니다. 두 사람이 같은 파일을 각자 고친 뒤 공유 폴더에 올리면 나중에 올린 쪽이 앞사람의 작업을 통째로 덮습니다. 덮인 사람은 대개 며칠 뒤에야 자기 코드가 사라진 것을 알아차립니다.

그래서 이력을 서버 한 곳에 모아 두는 도구가 먼저 나왔습니다. 파일을 고치려면 서버에 잠금을 걸고, 다 고치면 풀어 주는 방식입니다. 덮어쓰기는 막혔지만 대신 서버가 모든 일의 길목이 됐습니다. 네트워크가 끊기면 지난 기록을 볼 수도 없고, 한 사람이 잠금을 걸어 둔 채 퇴근하면 그 파일은 다음 날까지 아무도 못 고칩니다.

Git 은 이력을 한 곳에 두지 않는 쪽으로 방향을 틀었습니다. 저장소를 내려받으면 마지막 파일이 아니라 지금까지의 모든 기록이 함께 복사됩니다. 그래서 네트워크가 끊긴 비행기 안에서도 3년 전 기록을 뒤지고 새 기록을 남길 수 있고, 서버가 날아가도 참여자 수만큼의 사본이 남아 있습니다.

Git 이 실제로 없애 주는 것은 네 가지입니다. 각각이 앞 절의 불편에 하나씩 대응합니다.

1. 누가 언제 무엇을 왜 바꿨는지가 남습니다. 변경을 묶어 기록한 지점인 커밋마다 바뀐 줄과 설명 메시지가 붙습니다. 화면이 깨졌을 때 그 파일의 기록을 거꾸로 훑으면 어느 커밋부터 깨졌는지 몇 분 안에 좁힐 수 있습니다.
2. 여럿이 동시에 다른 일을 해도 서로를 막지 않습니다. 본류에서 갈라져 나온 작업 줄기인 브랜치를 각자 하나씩 파면, 결제 기능을 반쯤 만들어 둔 상태여도 옆 사람의 배포를 멈추지 않습니다.
3. 합칠 때 사람이 볼 것이 줄어듭니다. 갈라진 변경을 다시 하나로 만드는 머지는 서로 다른 줄을 건드린 수정을 자동으로 합칩니다. 사람이 손대는 것은 같은 줄을 서로 다르게 고쳐 기계가 고를 수 없는 충돌 부분뿐입니다.
4. 되돌리기가 싸집니다. 어제 배포한 기능이 장애를 냈을 때 그 커밋만 골라 취소하는 일이 한 줄 명령으로 끝납니다. 되돌리는 비용이 싸지면 시도하는 비용도 같이 싸집니다.

여기서 중요한 부작용이 하나 따라옵니다. 이력이 값싸고 안전해지면 합치기 전에 사람을 한 번 거치게 만들 수 있습니다. 내 브랜치를 본류에 합쳐 달라고 올리는 풀 리퀘스트와 그것을 동료가 읽는 코드 리뷰가 그 자리에서 만들어졌습니다. 잘못 합쳐도 되돌릴 수 있다는 전제가 없으면 이런 절차는 부담이 너무 커서 굴러가지 않습니다.

지금 새 프로젝트를 시작하면서 Git 말고 다른 것을 고르는 일은 거의 없지만, 다른 선택지가 없는 것은 아닙니다. 크게 셋으로 나뉩니다.

첫째는 이력을 서버 한 곳에만 두는 중앙집중식 도구입니다. Subversion 이 대표적이고, 게임 개발에서는 Perforce 가 아직 많이 쓰입니다. 남아 있는 이유는 큰 파일 때문입니다. 3기가바이트짜리 3D 모델 파일이 수천 개 있는 저장소에서는 전체 이력을 각자 컴퓨터에 복사하는 방식이 감당되지 않습니다. 한 파일에 잠금을 걸어 아예 동시 수정을 막는 기능도 합칠 수 없는 파일 형식에서는 유용합니다.

둘째는 Git 과 같은 분산형인 Mercurial 입니다. 이력을 통째로 복사하는 구조가 같고 할 수 있는 일도 거의 같습니다. 명령 체계가 더 정돈돼 있다는 평이 많았지만, 라이브러리와 배포 도구가 Git 쪽으로 몰리면서 지금은 쓰는 곳이 적습니다. 기술적 우열보다 주변 생태계가 승부를 갈랐습니다.

셋째는 파일 동기화 도구를 버전 관리 대신 쓰는 경우입니다. 공유 드라이브에도 예전 파일로 되돌리는 기능이 있으니 이력이 남기는 합니다. 없는 것은 합치는 기능입니다. 두 사람이 같은 파일을 고치면 한쪽을 고르거나 사본을 두 개 만들 뿐, 줄 단위로 섞어 주지는 못합니다.

셋을 견주면 선택 기준이 분명해집니다. 텍스트로 된 코드를 여럿이 고친다면 Git 입니다. 합칠 수 없는 큰 바이너리 파일이 주력이면 중앙집중식과 잠금이 여전히 답입니다.

"그 코드 언제부터 이랬는지 기록 좀 봐 주세요."

문제가 생긴 줄이 어느 커밋에서 들어왔는지 이력을 거슬러 찾아 달라는 말입니다.

"일단 브랜치 따서 작업하고 리뷰 받으시면 됩니다."

본류를 건드리지 말고 갈라진 줄기에서 작업한 뒤 합치기 전에 동료의 확인을 받으라는 안내입니다.

"어제 배포분에 문제가 있어서 해당 커밋만 되돌렸습니다."

전체를 이전 버전으로 돌리지 않고 문제가 된 변경 하나만 골라 취소했다는 보고입니다.

페이지덱에서는 새로 들어온 사람이 첫 주에 이 흐름을 한 번 통과합니다. 태오가 신입 개발자에게 맡기는 첫 과제는 도움말 문구 한 줄을 고치는 일입니다. 저장소를 내려받고, 브랜치를 하나 파고, 한 줄을 고쳐 커밋하고, 풀 리퀘스트를 올리고, 리뷰를 받아 합치기까지가 과제 하나에 다 들어 있습니다.

고치는 내용이 사소한 것은 의도한 설계입니다. 배우는 대상이 코드가 아니라 절차이기 때문입니다. 이 한 바퀴를 돌아 본 사람은 다음 주에 결제 코드를 고칠 때도 같은 경로를 씁니다.

Git 과 GitHub 을 같은 것으로 아는 경우가 가장 흔합니다. 둘을 따로 접할 일이 거의 없으니 그럴 만합니다. 신입에게 주는 안내서는 대개 GitHub 가입부터 시작하고, 실무 대화에서도 "깃에 올렸어요" 와 "깃허브에 올렸어요" 가 구분 없이 오갑니다.

실제로는 Git 이 도구이고 GitHub 은 그 도구가 만든 저장소를 인터넷에 두고 함께 쓰게 해 주는 서비스입니다. 풀 리퀘스트 화면과 리뷰 댓글은 Git 의 기능이 아니라 이 서비스가 얹은 것입니다. 둘을 붙여서 외우면 회선이 끊겼을 때 커밋도 못 한다고 여기거나, 서비스를 옮기는 논의를 도구를 바꾸는 논의로 착각하게 됩니다. 이력은 이미 각자 컴퓨터에 다 있으므로, 서비스를 옮기는 일은 사본을 다른 서버에 한 번 더 올리는 작업에 가깝습니다.