-
1. 시작하기
-
2. Git의 기초
- 2.1 Git 저장소 만들기
- 2.2 수정하고 저장소에 저장하기
- 2.3 커밋 히스토리 조회하기
- 2.4 되돌리기
- 2.5 리모트 저장소
- 2.6 태그
- 2.7 Git Alias
- 2.8 요약
-
3. Git 브랜치
-
4. Git 서버
- 4.1 프로토콜
- 4.2 서버에 Git 설치하기
- 4.3 SSH 공개키 만들기
- 4.4 서버 설정하기
- 4.5 Git 데몬
- 4.6 스마트 HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 또 다른 선택지, 호스팅
- 4.10 요약
-
5. 분산 환경에서의 Git
- 5.1 분산 환경에서의 워크플로
- 5.2 프로젝트에 기여하기
- 5.3 프로젝트 관리하기
- 5.4 요약
-
6. GitHub
- 6.1 계정 만들고 설정하기
- 6.2 GitHub 프로젝트에 기여하기
- 6.3 GitHub 프로젝트 관리하기
- 6.4 Organization 관리하기
- 6.5 GitHub 스크립팅
- 6.6 요약
-
7. Git 도구
- 7.1 리비전 조회하기
- 7.2 대화형 명령
- 7.3 Stashing과 Cleaning
- 7.4 내 작업에 서명하기
- 7.5 검색
- 7.6 히스토리 단장하기
- 7.7 Reset 명확히 알고 가기
- 7.8 고급 Merge
- 7.9 Rerere
- 7.10 Git으로 버그 찾기
- 7.11 서브모듈
- 7.12 Bundle
- 7.13 Replace
- 7.14 Credential 저장소
- 7.15 요약
-
8. Git맞춤
- 8.1 Git 설정하기
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 정책 구현하기
- 8.5 요약
-
9. Git과 여타 버전 관리 시스템
- 9.1 Git: 범용 Client
- 9.2 Git으로 옮기기
- 9.3 요약
-
10. Git의 내부
- 10.1 Plumbing 명령과 Porcelain 명령
- 10.2 Git 개체
- 10.3 Git Refs
- 10.4 Packfile
- 10.5 Refspec
- 10.6 데이터 전송 프로토콜
- 10.7 운영 및 데이터 복구
- 10.8 환경변수
- 10.9 요약
-
A1. 부록 A: 다양한 환경에서 Git 사용하기
- A1.1 GUI
- A1.2 Visual Studio
- A1.3 Eclipse
- A1.4 Bash
- A1.5 Zsh
- A1.6 Git in Powershell
- A1.7 요약
-
A2. 부록 B: 애플리케이션에 Git 넣기
-
A3. 부록 C: Git 명령어
- A3.1 설치와 설정
- A3.2 프로젝트 가져오기와 생성하기
- A3.3 스냅샷 다루기
- A3.4 Branch와 Merge
- A3.5 공유하고 업데이트하기
- A3.6 보기와 비교
- A3.7 Debugging
- A3.8 Patch 하기
- A3.9 Email
- A3.10 다른 버전 관리 시스템
- A3.11 관리
- A3.12 Plumbing 명령어
8.3 Git맞춤 - Git Hooks
Git Hooks
Git도 다른 버전 관리 시스템처럼 어떤 이벤트가 생겼을 때 자동으로 특정 스크립트를 실행하도록 할 수 있다. 이 훅은 클라이언트 훅과 서버 훅으로 나눌 수 있다. 클라이언트 훅은 커밋이나 Merge 할 때 실행되고 서버 훅은 Push 할 때 서버에서 실행된다. 이 절에서는 어떤 훅이 있고 어떻게 사용하는지 배운다.
훅 설치하기
훅은 Git 디렉토리 밑에 hooks
라는 디렉토리에 저장한다.
기본 훅 디렉토리는 .git/hooks
이다.
이 디렉토리에 가보면 Git이 자동으로 넣어준 매우 유용한 스크립트 예제가 몇 개 있다. 그리고 스크립트가 입력받는 값이 어떤 값인지 파일 안에 자세히 설명돼 있다.
모든 예제는 쉘과 Perl 스크립트로 작성돼 있지만 실행할 수만 있으면 되고 Ruby나 Python같은 익숙한 언어로 만들어도 된다.
예제 스크립트의 파일 이름에는 .sample
이라는 확장자가 붙어 있다. 그래서 이름만 바꿔주면 그 훅을 바로 사용할 수 있다.
실행할 수 있는 스크립트 파일을 확장자 없이 저장소의 hooks
디렉토리에 넣으면 훅 스크립트가 켜진다.
이 스크립트는 앞으로 계속 호출된다.
여기서는 주요 훅 몇 가지에 대해서 설명한다.
클라이언트 훅
클라이언트 훅은 매우 다양하다. 이 절에서는 클라이언트 훅을 committing-workflow 훅, email-workflow 스크립트, 그리고 나머지로 분류해서 설명한다.
노트
|
여기서 한가지 알아둘 점은 저장소를 Clone 해도 클라이언트 훅은 복사되지 않는다는 점이다. 만든 정책이 반드시 적용되도록 하려면 서버 훅을 이용해야만 하며 작성은 정책 구현하기 부분을 참고한다. |
커밋 워크플로 훅
먼저 커밋과 관련된 훅을 살펴보자. 커밋과 관련된 훅은 모두 네 가지다.
pre-commit
훅은 커밋할 때 가장 먼저 호출되는 훅으로 커밋 메시지를 작성하기 전에 호출된다.
이 훅에서 커밋하는 Snapshot을 점검한다. 빠트린 것은 없는지, 테스트는 확실히 했는지 등을 검사한다. 커밋할 때 꼭 확인해야 할 게 있으면 이 훅으로 확인한다.
그리고 이 훅의 Exit 코드가 0이 아니면 커밋은 취소된다. 물론 git commit --no-verify
라고 실행하면 이 훅을 일시적으로 생략할 수 있다.
lint
같은 프로그램으로 코드 스타일을 검사하거나, 라인 끝의 공백 문자를 검사하거나(예제로 들어 있는 pre-commit
훅이 하는 게 이 일이다), 새로 추가한 코드에 주석을 달았는지 검사하는 일은 이 훅으로 하는 것이 좋다.
prepare-commit-msg
훅은 Git이 커밋 메시지를 생성하고 나서 편집기를 실행하기 전에 실행된다.
이 훅은 사람이 커밋 메시지를 수정하기 전에 먼저 프로그램으로 손보고 싶을 때 사용한다.
이 훅은 커밋 메시지가 들어 있는 파일의 경로, 커밋의 종류를 아규먼트로 받는다. 그리고 최근 커밋을 수정할 때는(Amending 커밋) SHA-1 값을 추가 아규먼트로 더 받는다.
사실 이 훅은 일반 커밋에는 별로 필요 없고 커밋 메시지를 자동으로 생성하는 커밋에 좋다. 커밋 메시지에 템플릿을 적용하거나, Merge 커밋, Squash 커밋, Amend 커밋일 때 유용하다.
이 스크립트로 커밋 메시지 템플릿에 정보를 삽입할 수 있다.
commit-msg
훅은 커밋 메시지가 들어 있는 임시 파일의 경로를 아규먼트로 받는다.
그리고 이 스크립트가 0이 아닌 값을 반환하면 커밋되지 않는다. 이 훅에서 최종적으로 커밋이 완료되기 전에 프로젝트 상태나 커밋 메시지를 검증한다.
이 장의 마지막 절에서 이 훅을 사용하는 예제를 보여준다. 커밋 메시지가 정책에 맞는지 검사하는 스크립트를 만들어 보자.
커밋이 완료되면 post-commit
훅이 실행된다.
이 훅은 넘겨받는 아규먼트가 하나도 없지만 커밋 해시정보는 git log -1 HEAD
명령으로 쉽게 가져올 수 있다.
일반적으로 이 스크립트는 커밋된 것을 누군가 혹은 다른 프로그램에게 알릴 때 사용한다.
이메일 워크플로 훅
이메일 워크플로에 해당하는 클라이언트 훅은 세 가지이다.
이 훅은 모두 git am
명령으로 실행된다. 이 명령어를 사용할 일이 없으면 이 절은 읽지 않아도 된다.
하지만, 언젠가는 git format-patch
명령으로 만든 Patch를 이메일로 받는 날이 올지도 모른다.
제일 먼저 실행하는 훅은 applypatch-msg
이다.
이 훅의 아규먼트는 Author가 보내온 커밋 메시지 파일의 이름이다.
이 스크립트가 종료할 때 0이 아닌 값을 반환하면 Git은 Patch 하지 않는다.
커밋 메시지가 규칙에 맞는지 확인하거나 자동으로 메시지를 수정할 때 이 훅을 사용한다.
git am
으로 Patch 할 때 두 번째로 실행되는 훅이 pre-applypatch
이다.
이 훅은 아규먼트가 없고 단순히 Patch를 적용하고 나서 실행된다. 그래서 커밋할 스냅샷을 검사하는 데 사용한다.
이 스크립트로 테스트를 수행하고 파일을 검사할 수 있다.
테스트에 실패하거나 뭔가 부족하면 0이 아닌 값을 반환시켜서 git am
명령을 취소시킬 수 있다.
git am
명령에서 마지막으로 실행되는 훅은 post-applypatch
다.
이 스크립트를 이용하면 자동으로 Patch를 보낸 사람이나 그룹에게 알림 메시지를 보낼 수 있다.
이 스크립트로는 Patch를 중단시킬 수 없다.
기타 훅
pre-rebase
훅은 Rebase 하기 전에 실행된다. 이 훅이 0이 아닌 값을 반환하면 Rebase가 취소된다.
이 훅으로 이미 Push 한 커밋을 Rebase 하지 못하게 할 수 있다.
Git이 자동으로 넣어주는 pre-rebase
예제가 바로 그 예제다. 이 예제에는 기준 브랜치가 next
라고 돼 있다. 참고하여 실제로 적용할 브랜치 이름으로 사용하면 된다.
post-rewrite
훅은 커밋을 변경하는 명령을 실행했을 때 실행된다. 예를 들어 git commit --amend
이나 git rebase
같은 명령이 해당한다. git filter-branch
명령은 해당하지 않는다.
아규먼트로 커밋을 변경하게 한 명령이 전달되고 stdin
으로 변경된 커밋 목록이 전달된다.
훅의 용도는 post-checkout
이나 post-merge
훅과 비슷하다고 볼 수 있다.
디렉토리에서 뭔가 할 일이 있을 때 사용한다. 그러니까 용량이 크거나 Git이 관리하지 않는 파일을 옮기거나, 문서를 자동으로 생성하는 데 쓴다.
post-merge
훅은 Merge가 끝나고 나서 실행된다.
이 훅은 파일 권한 같이 Git이 추적하지 않는 정보를 관리하는 데 사용한다.
Merge로 Working Tree가 변경될 때 Git이 관리하지 않는 파일이 원하는 대로 잘 배치됐는지 검사할 때도 좋다.
pre-push
훅은 git push
명령을 실행하면 동작하는데 리모트 정보를 업데이트 하고 난 후 리모트로 데이터를 전송하기 전에 동작한다.
리모트의 이름과 주소를 파라미터로 전달받으며 stdin
을 통해 업데이트 할 해시 리스트를 전달받는다.
Push 하기 전에 커밋이 유효한지 확인하는 용도로 사용할 수 있다. 훅에서 0이 아닌 값을 반환하면 Push를 중지시킨다.
Git은 정상적으로 동작하는 중에도 이따금 git gc --auto
명령으로 가비지 컬렉션을 동작시킨다.
pre-auto-gc
훅은 가비지 컬렉션이 실행되기 직전에 호출되는 훅으로 가비지 컬렉션이 동작한다고 사용자에게 알려주거나 지금 시점에 가비지 컬렉션이 동작하기엔 좋지 않다고 Git에 알려주는 용도로 사용할 수 있다.
서버 훅
클라이언트 훅으로도 어떤 정책을 강제할 수 있지만, 시스템 관리자에게는 서버 훅이 더 중요하다. 서버 훅은 모두 Push 전후에 실행된다. Push 전에 실행되는 훅이 0이 아닌 값을 반환하면 해당 Push는 거절되고 클라이언트는 에러 메시지를 출력한다. 이 훅으로 아주 복잡한 Push 정책도 가능하다.
pre-receive
Push 하면 가장 처음 실행되는 훅은 pre-receive
훅이다.
이 스크립트는 표준 입력(STDIN)으로 Push 하는 Refs의 목록을 입력받는다. 0이 아닌 값을 반환하면 해당 Refs가 전부 거절된다.
Fast-forward Push가 아니면 거절하거나, 브랜치 Push 권한을 제어하려면 이 훅에서 하는 것이 좋다. 관리자만 브랜치를 새로 Push 하고 삭제할 수 있고 일반 개발자는 수정사항만 Push 할 수 있게 할 수 있다.
update
update 스크립트는 각 브랜치마다 한 번씩 실행된다는 것을 제외하면 pre-receive
스크립트와 거의 같다.
한 번에 브랜치를 여러 개 Push 하면 pre-receive
는 딱 한 번만 실행되지만, update는 브랜치마다 실행된다.
이 스크립트는 표준 입력으로 데이터를 입력받는 것이 아니라 아규먼트로 브랜치 이름, 원래 가리키던 SHA-1 값, 사용자가 Push 하는 SHA-1 값을 입력받는다.
update 스크립트가 0이 아닌 값을 반환하면 해당 Refs만 거절되고 나머지 다른 Refs는 상관없다.
post-receive
post-receive
훅은 Push 한 후에 실행된다. 이 훅으로 사용자나 서비스에 알림 메시지를 보낼 수 있다.
그리고 pre-receive
훅처럼 표준 입력(STDIN)으로 Refs 목록이 넘어간다.
이 훅으로 메일링리스트에 메일을 보내거나, CI(Continuous Integration) 서버나 Ticket-tracking 시스템의 정보를 수정할 수 있다. 심지어 커밋 메시지도 파싱할 수 있기 때문에 이 훅으로 Ticket을 만들고, 수정하고, 닫을 수 있다.
이 스크립트가 완전히 종료할 때까지 클라이언트와의 연결은 유지되고 Push를 중단시킬 수 없다. 그래서 이 스크립트로 시간이 오래 걸릴만한 일을 할 때는 조심해야 한다.