クイズ: クライアント側フック

core.hooksPath 를 .githooks 로 지정하는 이유는?

• .git/hooks 는 clone 으로 따라오지 않아 훅을 저장소에 담아 공유하려고
• .git/hooks 에 둔 훅은 실행 권한이 자동으로 사라지기 때문에
• 훅이 저장소 밖 경로를 읽지 못하도록 막기 위해
• 여러 저장소가 같은 훅 디렉터리를 공유하게 만들려고

pre-commit 훅이 검사 대상을 인덱스에서 읽어야 하는 이유는?

• 작업 트리 파일은 훅이 실행되는 동안 잠겨 읽을 수 없기 때문
• 인덱스에서 읽어야 이름이 바뀐 파일까지 추적되기 때문
• 커밋되는 것은 인덱스의 내용이고 작업 트리는 git add 뒤에 달라질 수 있기 때문
• 작업 트리에는 .gitignore 로 무시된 파일이 섞여 있기 때문

pre-push 훅이 어떤 참조가 올라가는지 아는 방법은?

• 환경 변수 GIT_PUSH_REFS 를 읽는다
• 표준 입력으로 오는 로컬참조 로컬해시 원격참조 원격해시 줄을 읽는다
• git rev-parse --symbolic-full-name HEAD 로 현재 브랜치를 본다
• 첫 번째 인자로 넘어오는 참조 이름을 읽는다

훅 파일을 만들었는데 아무 일도 일어나지 않는다. 가장 먼저 볼 것은?

• 훅 파일의 줄 끝 문자가 LF 인지
• 훅 파일 이름에 확장자가 붙어 있는지
• 훅이 표준 출력 대신 표준 오류로 쓰고 있는지
• 훅 파일에 실행 권한이 있는지

클라이언트 훅으로 규칙을 강제할 수 없는 이유로 옳지 않은 것은?

• --no-verify 로 건너뛸 수 있다
• core.hooksPath 설정이 clone 으로 따라오지 않는다
• 훅은 원격 저장소가 거부한 push 를 되돌릴 수 없다
• 웹 편집기나 다른 도구로 들어오는 변경에는 실행되지 않는다

같은 규칙을 클라이언트 훅과 서버 양쪽에 거는 이유는?

• 서버 훅이 실패하면 클라이언트 훅이 대신 실행되기 때문
• 클라이언트는 몇 초 만에 알려 주고 서버는 끝내 막아 주기 때문
• 두 곳에 걸어야 git 이 규칙을 이력에 기록하기 때문
• 클라이언트 훅만으로는 커밋 메시지를 검사할 수 없기 때문