규칙을 훅에 걸었는데 한 낱말로 뚫렸다

목표

저장소에 담아 공유되는 클라이언트 훅 셋을 만들고, 그것이 무엇을 막고 무엇을 못 막는지
직접 확인합니다.

왜 중요한가

훅은 "규칙을 자동화한다" 는 말로 소개되지만, 클라이언트 훅이 실제로 하는 일은 **빠른
피드백**입니다. 강제가 아닙니다. 이 차이를 모르고 규칙을 클라이언트에만 걸어 두면,
지켜지고 있다고 믿는 상태로 오래 갑니다. 이 실습은 그 믿음을 직접 깨 봅니다 — 규칙을
셋 만들고, 한 낱말로 전부 지나갑니다. 그리고 pre-commit 이 작업 트리를 읽으면 왜
안 되는지를, 인덱스에만 비밀이 있는 상태를 만들어 확인합니다. 커밋되는 것은 인덱스이지
작업 트리가 아니라는 사실은 훅을 쓰지 않더라도 알아 둘 값이 있습니다.

단계

1. /root/gitx9/repo 를 만들고 core.hooksPath 를 .githooks 로 지정합니다.
2. .githooks/commit-msg 로 제목 형식을 강제하고, 거절당한 기록을 notes/reject.txt 에
남깁니다.
3. .githooks/pre-commit 으로 100000 바이트를 넘는 파일을 막고 notes/bigfile.txt 에
남깁니다.
4. 그 훅이 인덱스를 보게 고쳐 AKIA 로 시작하는 문자열을 막고, 작업 트리만 보면
왜 뚫리는지를 notes/index.txt 에 남깁니다.
5. --no-verify 로 규칙을 어긴 커밋을 하나 만들고 notes/bypass.txt 에 남깁니다.
6. /root/gitx9/clone 을 떠서 무엇이 따라오고 무엇이 안 따라오는지를
notes/share.txt 에 남깁니다.
7. /root/gitx9/origin.git 을 만들고 .githooks/pre-push 로 main 직접 push 를 막아
notes/prepush.txt 에 남깁니다.
8. notes/report.md 에 클라이언트 훅과 서버 훅의 역할을 정리합니다.

참고

• 훅 파일에는 반드시 실행 권한(chmod +x)을 주세요. 없으면 git 이 조용히 건너뜁니다.
• 이 이미지에는 python3 이 없습니다. 훅은 sh 와 git·grep·awk 로 씁니다.
• 4단계의 시험 문자열은 AKIAIOSFODNN7EXAMPLE 입니다. 패턴은 AKIA 뒤에 대문자·숫자

16자로 잡으세요.

• 흔한 실수: 훅을 만들고 커밋하지 않는 것입니다. 저장소에 담겨야 공유됩니다.
• 흔한 실수: 7단계에서 main 을 끝내 push 해 버리는 것입니다. 막히는 것을 확인하고

기능 브랜치만 올려야 합니다.

단계 8개

1. 훅을 저장소 안에 두기로 한다
2. 제목 형식을 강제한다
3. 큰 파일을 커밋 전에 막는다
4. 커밋되는 것은 작업 트리가 아니라 인덱스다
5. 한 낱말로 전부 지나간다
6. 훅 파일은 따라오고 설정은 안 따라온다
7. 보호 브랜치를 클라이언트에서 막아 본다
8. 어느 자리가 알려 주고 어느 자리가 막는가