커밋

변경 이력을 남기는 도구가 자리 잡기 전에는 폴더를 통째로 복사해 두는 것이 이력의 전부였습니다. 프로젝트_0512, 프로젝트_0512_수정, 프로젝트_최종 같은 이름이 한 디렉터리에 나란히 쌓였고, 그중 어느 것이 지금 돌아가는 코드인지는 만든 사람 머릿속에만 있었습니다.

이 방식은 무언가 망가지는 순간 무너졌습니다. 지난주까지 열리던 결제 화면이 오늘 안 열리면 물어볼 데가 사람뿐이었습니다. "그 사이에 뭐 바꾸셨어요" 하고 물으면 "결제 쪽이랑 로그인 쪽을 좀 만지긴 했는데요" 라는 답이 돌아오고, 그 뒤로는 둘이 앉아 어제 것과 오늘 것을 눈으로 비교했습니다. 무엇을 언제 왜 바꿨는지가 어디에도 적혀 있지 않으니 원인을 찾는 일이 기억을 더듬는 일이 됐습니다.

커밋은 그 기억을 파일 바깥으로 꺼내 놓은 장치입니다. 파일을 저장하는 일과 별개로 "여기까지가 한 덩어리의 변경이고 이유는 이것" 이라고 선을 긋는 행위를 따로 두었습니다. 선이 그어져 있으면 나중에 온 사람도 그 선을 따라 이력을 읽을 수 있고, 필요할 때 선 하나만 골라 지울 수 있습니다.

커밋은 파일을 저장하는 순간 저절로 생기지 않습니다. 사람이 무엇을 담을지 고른 다음 직접 만듭니다. 세 단계로 이뤄집니다.

1. 파일을 고칩니다. 여기까지는 아무 기록도 남지 않고, 고친 내용은 내 컴퓨터에만 있습니다.
2. 고친 것 가운데 이번 기록에 담을 것만 고릅니다. 오전에 버그 하나를 잡고 오후에 글꼴을 바꿨다면 지금은 버그 수정만 담고 글꼴은 다음 기록으로 미룰 수 있습니다. 이렇게 담을 것을 따로 추려 두는 자리를 스테이징이라고 부릅니다.
3. 메시지를 붙여 확정합니다. 메시지는 무엇을 했는지보다 왜 했는지를 적을수록 오래 쓸모가 갑니다. "코드 수정" 보다 "공유 링크 만료 시간이 항상 0으로 계산되던 문제 수정" 이 낫습니다.

확정된 기록 안에는 네 가지가 함께 들어갑니다. 바뀐 줄의 내용, 만든 사람과 시각, 메시지, 그리고 직전 커밋을 가리키는 연결입니다. 마지막 항목 덕분에 커밋은 낱개가 아니라 사슬이 됩니다. 사슬을 거슬러 올라가면 저장소를 처음 만든 날까지 한 줄로 이어지고, 그래서 "3주 전 화요일 상태" 같은 지점으로 정확히 돌아갈 수 있습니다.

기록마다 고유한 이름표도 붙습니다. a3f9c21 처럼 생긴 문자열인데 실제로는 마흔 자리이고 대화에서는 앞 일곱 자리만 잘라 씁니다. 1, 2, 3 처럼 순번을 쓰지 않는 이유는 여러 사람이 각자의 컴퓨터에서 동시에 기록을 만들기 때문입니다. 순번을 쓰면 같은 번호가 두 군데서 생깁니다.

한 커밋의 크기를 정하는 기준은 하나입니다. 한 덩어리에 한 가지 이유만 담습니다. 버그 수정과 글꼴 교체를 같이 넣으면 나중에 글꼴만 되돌리려 할 때 방법이 없습니다. 반대로 한 줄 고칠 때마다 기록을 만들면 이력이 잡음으로 차서 읽을 수 없게 됩니다.

커밋이 쌓이는 자리는 브랜치입니다. 브랜치는 본류를 건드리지 않고 따로 작업하려고 갈라 둔 줄기이고, 그 위에 커밋을 여러 개 올린 뒤 통째로 합칩니다. 합쳐 달라고 올리는 요청이 풀 리퀘스트이고, 동료가 그 요청을 읽고 의견을 남기는 절차가 코드 리뷰입니다. 리뷰어는 바뀐 파일 전체를 한 번에 보기도 하지만, 커밋이 이유별로 나뉘어 있으면 하나씩 따라 읽으면서 작업 순서를 그대로 재생할 수 있습니다.

원인을 찾을 때도 이 단위가 기준이 됩니다. 어제까지 되던 기능이 오늘 안 되면 그 사이의 커밋을 하나씩 되짚어 어느 기록부터 깨졌는지를 좁혀 갑니다. 커밋이 잘게 나뉘어 있으면 범위가 열 줄 안쪽으로 줄지만, 사흘치 작업을 한 덩어리로 올려 뒀다면 400줄을 다 뒤져야 합니다. 범인을 찾은 뒤 그 기록만 골라 취소하는 것이 롤백이고, 이것도 커밋이 이유별로 나뉘어 있을 때만 깔끔하게 됩니다.

자동 검사도 커밋을 신호로 씁니다. 새 기록이 올라올 때마다 테스트를 돌려 통과 여부를 알려 주는 방식을 지속적 통합이라고 하는데, 여기서 "언제" 에 해당하는 것이 커밋이 올라온 시점입니다.

"이 커밋 하나에 너무 많이 들어갔어요. 두세 개로 쪼개서 다시 올려 주실래요?"

리뷰하기도 어렵고 나중에 일부만 되돌릴 수도 없으니 이유 단위로 나눠 달라는 요청입니다.

"언제부터 깨졌는지 커밋 하나씩 짚어 보면 나올 거예요."

되던 시점과 안 되는 시점 사이의 기록을 차례로 확인해 원인이 들어간 지점을 찾자는 말입니다.

"커밋 메시지에 티켓 번호 좀 붙여 주세요."

이 변경이 어떤 요청에서 시작됐는지 나중에 거슬러 올라갈 수 있게 해 달라는 뜻입니다.

페이지덱에서 태오가 문서 공유 링크 기능을 만들 때의 일입니다. 사흘 동안 작업하면서 링크 생성, 만료 시간 처리, 권한 확인, 오류 화면을 각각 따로 기록해 커밋 일곱 개로 올렸습니다. 배포 다음 날 지현이 "어제부터 공유 링크가 하루 만에 만료된다는 문의가 들어온다" 고 전했고, 태오는 일곱 개 가운데 만료 시간을 다루는 두 개만 열어 보고 십 분 만에 잘못 계산된 줄을 찾았습니다.

같은 작업을 "공유 링크 기능" 이라는 커밋 하나로 올렸다면 그 자리에서 열어 볼 것이 바뀐 파일 전부였습니다. 커밋을 나누는 품은 작업할 때 들지만, 그 값은 문제가 생긴 날에 돌아옵니다.

커밋하면 다른 사람에게도 바로 보인다고 생각하는 경우가 많습니다. 저장 버튼과 비슷한 것으로 느껴지니 자연스러운 오해입니다. 하지만 커밋은 내 컴퓨터 안의 이력에만 남고, 공유되려면 원격 저장소로 올리는 동작을 따로 해야 합니다. 이걸 모르면 하루치 작업을 커밋해 두고 "올렸어요" 라고 말한 뒤 아무도 그 코드를 못 받는 상황이 생깁니다.

작업이 다 끝났을 때 한 번만 하는 것이라는 오해도 흔합니다. 기록이라는 말이 결과를 남기는 일처럼 들리기 때문입니다. 실제로는 작업 도중에 의미가 생길 때마다 남기는 쪽이 맞습니다. 끝까지 미루면 사흘치가 한 덩어리가 되어 되돌릴 지점도 사라지고, 중간에 잘못된 방향으로 갔을 때 돌아갈 자리도 없습니다.