학습 자료

커밋 메시지 쓰는 법 — 석 달 뒤의 내가 읽습니다


Article

일기장을 한 권 삽니다. 첫 장에 제목을 씁니다. "일기". 다음 장에도 "일기". 그다음 장에도 "일기".

석 달 뒤에 그 일기장을 펴서 제주도 갔던 날 쓴 글을 찾아봅니다. 못 찾습니다. 목차를 봐도 "일기 · 일기 · 일기" 뿐이라, 결국 첫 장부터 한 장씩 다 넘겨봐야 합니다.

이번 시간에는 명령어를 하나도 배우지 않습니다. 이미 아는 git commit -m "..." 에서 따옴표 안에 뭘 적을 것인가, 그것만 다룹니다. 시시해 보이지만, 지금까지 배운 것 중에 석 달 뒤의 나에게 가장 크게 돌아오는 건 이겁니다.

석 달 뒤의 나를 먼저 만나봅니다

처음 깃을 배운 사람의 저장소에서 실제로 자주 보이는 기록입니다. 7강에서 배운 git log --oneline 으로 훑어본 모습입니다.

Git Bash
  • $ git log --oneline
  • a91c0f4 수정2
  • 77db3e2 수정
  • 0c5a8b9 ㅁㄴㅇㄹ
  • b3e7f10 ㅇㅇ
  • 4d2a6c8 .
  • 1f8b0d3 asdf

이 목록을 보고 대답할 수 있는 게 하나도 없습니다. 어제 뭘 했는지, 지난주에 고친 게 어느 줄이었는지, 잘 돌아가던 게 언제부터 망가졌는지. 전부 모릅니다.

기록은 남아 있습니다. 읽을 수가 없을 뿐입니다. 그러면 남긴 의미가 없습니다.

같은 작업, 다른 목차

제목이 전부 "일기"

읽을 수 없는 기록

  • 찾으려면 처음부터 다 넘겨야 한다
  • 언제 뭐가 바뀌었는지 모른다
  • 결국 안 보게 된다

"제주도 첫날 · 비행기 놓칠 뻔한 날"

읽을 수 있는 기록

  • 목차만 훑어도 찾는 날이 보인다
  • 그날 무슨 일이 있었는지 제목만으로 안다
  • 석 달 뒤에도 쓸모가 있다
일기장의 가치는 쓴 양이 아니라 찾아 읽을 수 있느냐로 결정된다

이 칸은 누구에게 쓰는 것인가

여기서 오해가 하나 풀려야 합니다. 커밋 메시지는 깃에게 하는 말이 아닙니다. 깃은 그 글자를 읽지도, 판단하지도 않습니다. 뭘 적든 커밋은 똑같이 만들어집니다.

메시지를 읽는 건 사람입니다. 그것도 지금의 내가 아니라 나중의 누군가입니다.

지금 커밋 메시지를 아무렇게나 쓰면, 저 세 사람이 전부 손해를 봅니다. 그리고 셋 다 결국 나입니다.

무엇을 적는가 — 딱 하나만 지킵니다

원칙은 하나로 줄일 수 있습니다.

이 커밋 전과 후에 무엇이 달라졌는지를 한 줄로 적는다.

"내가 무슨 작업을 했다"가 아니라 "무엇이 달라졌다"입니다. 미묘하지만 결과가 크게 다릅니다. "작업함", "수정" 은 전자고, "메모에 연락처 줄 추가" 는 후자입니다.

쓰는 순서도 세 단계면 끝납니다. 7강에서 배운 git diff 로 바뀐 곳을 눈으로 보고, "이번에 나는 ___ 를 했다" 의 빈칸을 소리 내어 채워보고, 그 문장을 그대로 적습니다. 꾸미지 않습니다.

말로는 다들 잘합니다. 옆 사람이 "지금 뭐 했어?" 라고 물으면 "메모에 연락처 한 줄 넣었어" 라고 정확하게 대답합니다. 그런데 터미널 앞에만 앉으면 그게 "수정" 이 됩니다. 말한 걸 그대로 옮기면 됩니다.

고쳐 쓰기 — 왼쪽을 오른쪽으로
이렇게 쓰던 것이렇게 바꾼다
수정메모 오타 고침무엇을 수정했는지가 빠져 있었다
추가연락처 줄 추가무엇을 추가했는지가 빠져 있었다
ㅁㄴㅇㄹ제목 문구 변경칸을 채우려고 아무거나 친 것이다
작업중인사말 세 줄로 늘림"작업중" 아닌 커밋은 없다
파일 수정함메모에서 옛 주소 삭제어느 파일을 어떻게 했는지 적는다
최종메모 내용 정리 마무리"최종" 은 1강에서 이미 실패한 방식이다
오른쪽이 특별히 길지 않다. 열 글자 안팎이면 충분하다

마지막 줄이 중요합니다. 1강에서 보고서_최종_최종2_진짜최종 폴더를 보며 시작했는데, 커밋 메시지에 최종 이라고 적는 건 같은 실수를 저장소 안에서 다시 하는 것입니다. 이름으로 버전을 구분하려던 습관이 여기까지 따라옵니다.

직접 고쳐 써봅니다

지금까지 만든 저장소로 확인해봅니다. 우선 어디까지 왔는지 봅니다.

Git Bash
  • $ git log --oneline
  • 5a7b3f2 (HEAD -> master) 제외 규칙 추가
  • c1d5e08 메모 내용 다듬고 한 줄 추가
  • 8f4c2a1 메모에 한 줄 추가
  • 3e9b7d1 메모 파일 추가

네 줄 다 읽힙니다. 훌륭하지는 않아도 무엇이 달라졌는지는 전부 적혀 있습니다. 지금까지 잘 따라온 겁니다.

여기에 한 줄을 더 쌓아봅니다.

메시지를 정하고 커밋하기
  1. 01

    memo.txt 를 열어 한 줄을 고칩니다

    아무 줄이나 하나 골라 문장을 바꿔 씁니다. 그리고 저장합니다

  2. 02

    git diff 로 뭐가 달라졌는지 봅니다

    메시지를 쓰기 전에 먼저 봅니다. 보지 않고 쓰니까 "수정" 이 나옵니다

  3. 03

    소리 내어 한 문장으로 말해봅니다

    "메모 마지막 줄 문구를 바꿨다" 처럼 말합니다

  4. 04

    git add memo.txt

    6강의 장바구니에 담습니다

  5. 05

    말한 그대로 커밋합니다

    git commit -m "메모 마지막 줄 문구 변경"
  6. 06

    git log --oneline 으로 확인합니다

    새 줄이 맨 위에 붙습니다

두 번째 단계를 건너뛰지 않는 것이 이 강의의 전부다
Git Bash
  • $ git log --oneline
  • e2f9c40 (HEAD -> master) 메모 마지막 줄 문구 변경
  • 5a7b3f2 제외 규칙 추가
  • c1d5e08 메모 내용 다듬고 한 줄 추가
  • 8f4c2a1 메모에 한 줄 추가
  • 3e9b7d1 메모 파일 추가

다섯 줄짜리 목차가 생겼습니다. 이 목록만 위에서 아래로 읽으면, 이 폴더에서 지금까지 무슨 일이 있었는지 순서대로 파악됩니다. 파일을 하나도 열어보지 않고 말입니다. 그게 잘 쓴 커밋 메시지가 하는 일입니다.

메시지가 안 써지면 메시지 탓이 아닙니다

여기서 이 강의의 진짜 내용이 나옵니다. 커밋하려는데 한 줄로 요약이 안 될 때가 있습니다. 이렇게 됩니다.

"메모 문구 고치고 제외 규칙도 손보고 파일 이름도 바꿈"

"그리고" 나 "도" 가 들어가면 신호입니다. 메시지를 잘 못 쓰는 게 아니라, 커밋을 잘못 묶은 겁니다. 서로 상관없는 작업 세 개를 한 봉투에 넣어놓고 봉투에 이름을 붙이려니 안 붙는 것입니다.

한 봉투에 다 넣기 vs 나눠 담기

커밋 하나에 몰아넣기

메시지가 길고 흐릿해진다

  • 문구 고치고 규칙 손보고 이름 바꿈
  • 셋 중 하나만 되돌리고 싶어도 방법이 없다
  • 나중에 문제가 생기면 어느 작업 탓인지 못 가린다
  • "이날 뭔가 많이 했다" 외에는 안 남는다

세 번 나눠 커밋

각각 한 줄로 깔끔하다

  • 메모 마지막 줄 문구 변경
  • 제외 규칙에 임시 폴더 추가
  • 메모 파일 이름 정리
  • 하나만 골라 되돌릴 수 있다
커밋 단위와 메시지는 한 몸이다. 메시지가 안 써지면 단위를 의심한다

그래서 커밋을 작게, 자주 하게 됩니다. 8강에서 "커밋에 없는 것은 깃도 못 살린다" 고 한 이유와 여기서 만납니다. 자주 커밋하면 살릴 수 있는 지점이 촘촘해지고, 메시지도 저절로 짧고 명확해집니다. 하루 종일 작업하고 저녁에 한 번 커밋하는 습관이 제일 나쁩니다.

커밋하기 전에 스스로 물어보는 세 가지
  1. 01

    이 메시지만 보고 석 달 뒤의 내가 알아볼까

    "수정" 은 이 질문에서 바로 걸립니다

  2. 02

    "그리고" 나 "도" 가 들어갔나

    들어갔으면 커밋을 둘로 나눕니다. 메시지를 다듬을 일이 아닙니다

  3. 03

    git diff 를 보고 쓴 게 맞나

    안 보고 썼다면 십중팔구 실제로 바뀐 것과 메시지가 다릅니다

세 질문에 답하는 데 십 초면 된다. 그 십 초가 석 달 뒤를 바꾼다

정리하면

  • 커밋 메시지는 일기 제목입니다. 전부 "일기" 라고 써두면 목차가 있어도 못 찾습니다
  • 메시지를 읽는 건 깃이 아니라 사람입니다. 석 달 뒤의 나 · 같이 일하는 사람 · 나를 보는 사람
  • 적을 내용은 하나입니다. 이 커밋 전과 후에 무엇이 달라졌는지를 한 줄로
  • 잘 쓰려고 애쓰지 않습니다. git diff 로 보고, 한 문장으로 말해보고, 말한 그대로 적습니다
  • 수정 · ㅁㄴㅇㄹ · 작업중 · 최종 은 전부 무엇이 달라졌는지가 빠진 말입니다
  • 한글로 써도 됩니다. 한 줄 · 오십 자 안쪽이면 충분하고, 마침표는 안 찍습니다
  • "그리고" 가 들어가면 메시지 문제가 아니라 커밋 단위 문제입니다. 둘로 나눕니다
  • 그래서 커밋은 작게, 자주 합니다. 메시지도 짧아지고 되돌릴 지점도 촘촘해집니다
  • 나중에 고치려 하지 말고 칠 때 제대로 칩니다. 직전 커밋을 고치는 법은 26강에서 다룹니다

Part 2 가 끝났습니다. 6강부터 여기까지, 혼자서 기록을 남기고 읽고 되돌리는 것을 전부 해봤습니다. addcommit 으로 쌓고, logdiff 로 읽고, restore 로 되돌리고, .gitignore 로 걸러내고, 마지막으로 그 기록을 읽을 수 있게 쓰는 법까지 왔습니다. 아직 인터넷에는 아무것도 올리지 않았습니다. 여기까지가 전부 내 컴퓨터 안에서 일어난 일입니다.

다음 11강부터 Part 3 입니다. 깃을 잠깐 내려놓고 마크다운을 배웁니다. 화장을 안 한 문서라고 생각하면 됩니다. 태그를 잔뜩 두르지 않고 # 하나로 제목을 만드는 표기법인데, 세 강만 투자하면 깃허브 · 노션 · 옵시디언에서 평생 씁니다. 우리가 키워온 memo.txt 도 이때 memo.md 로 다시 태어납니다.

커밋 메시지 쓰는 법 — 석 달 뒤의 내가 읽습니다 — 디코드랩(DCODELAB)