この記事は？
Git Hooks での、コミット生成の制御と push 受け取りの制御について学んだのでメモ。
Git の運用ルール (コミットメッセージやブランチ名のルール等) を、スクリプトで規制したい、という方に役立てられれば幸いです。
Git の基礎的な使い方が分かっていること、シェルスクリプトがある程度読める・書けることを前提に話を進めます。
Git Hooks とは？
Git Hooks というのは、Git で何らかのアクション (例: コミットを作成, マージ, リモートへ Push 等) が発生した際に、特定のプログラム (主にシェルスクリプト) を実行する仕組みです。
検出できるアクションはいくつかあります。
こちらの記事で図に分けて説明してくださっています。
これら全てを活用するのは、本格的で大規模な開発であるときと思います。
この記事では、コミット関係 (クライアントサイド) と、push 受け取り関係 (サーバサイド) を扱います。
Git Hooks スクリプトの置き場所
クライアントサイド (ローカルリポジトリ) では、リポジトリのルート上から.git/hooks/ (隠しフォルダ) に。
サーバサイド (リモートリポジトリ) では、リポジトリのルート上からhooks/に。
このディレクトリに、各アクションに対応するファイル名で、スクリプトを配置します。
ls .git/hooks/
# applypatch-msg.sample* pre-merge-commit.sample*
# commit-msg.sample* pre-push.sample*
# fsmonitor-watchman.sample* pre-rebase.sample*
# post-update.sample* pre-receive.sample*
# pre-applypatch.sample* prepare-commit-msg.sample*
# pre-commit.sample* update.sample*
デフォルトでは、.sampleと書かれたサンプルのプログラム (シェルスクリプト) が配置されています。
Git Hooks を動作させる際には、対応させるアクションのファイル名で、.sampleを付けず、プログラムを配置します。(実行権限の付与もお忘れなく。)
また、リモートリポジトリ上のhooks/と、ローカルリポジトリ上の.git/hooks/は、クローン (同期) されません。
そのため、開発者全員に特定のルールに沿った Git Hooks を使用させるには、別途設定をさせる必要があります。
(一見すると不便な仕様に見えるかもしれませんが、悪意あるスクリプトを実行させないためでしょう。特に、GitHub 等で公開されているオープンなリポジトリでは。)
コミット関係 (クライアントサイド)
コミットに関する Git Hooks は、全部で 4つあります。
Git でのコミット生成の動作と合わせて説明すると、以下のように呼び出されます。
-
git commitが実行される - ---
pre-commitが実行される - (1. で
-m "<message>"オプションがあったなら、<message>が書き込まれた).git/COMMIT_EDITMSGが生成される - ---
prepare-commit-msgが実行される - (1. で
-m <message>オプションが無かったなら).git/COMMIT_EDITMSGの編集が開始される - ---
commit-msgが実行される - コミットが生成される
- ---
post-commitが実行される
pre-commit prepare-commit-msg commit-msgにおいて、exit 1等のように、0 以外の返り値が発生した場合、その時点でコミットの動作が中止 (reject) されます。
commit-msgは、コミット生成の直前に呼び出されますので、入力されたコミットメッセージが指定の書式に沿っているかのチェックに応用できます。
メッセージの書式が正しく無い場合は、コミットを生成できない、というようにすることが可能です。
post-commitは、コミットが正常に完了したら呼び出されますので、通知等に応用できます。
post-commitが実行された段階では、既にコミットは完了していますので、返り値が何であろうと中止はされません。
#!/bin/sh
# /.git/hooks/prepare-commit と /.git/hooks/commit-msg で同じ結果が得られる
echo $1 # 結果例: .git/COMMIT_EDITMSG
cat $1 # 結果例: any commit message
exit 0
prepare-commit-msg commit-msgが呼び出される際、第一引数には、コミットメッセージの書かれたファイルCOMMIT_EDITMSGへのパスが入力されます。
pre-commit post-commitでは、引数は入力されません。
git-logやgit rev-parseコマンド等で、リポジトリの情報を取得して、何らかの動作をさせます。
commit-msgについて、実装例を作ってみました:
push 受け取り関係 (サーバサイド)
push に関する Git Hooks は、全部で 4つあります。
Git でのコミット生成の動作と合わせて説明すると、以下のように呼び出されます。
-
git pushが実行される - ---
pre-receiveが実行される - ---
updateが、更新されたブランチ全てに実行される - push が適用される
- ---
post-receiveが実行される
pre-receive updateにおいて、0 以外の返り値が発生した場合、その時点で push 受け取りが中止 (reject) されます。
post-receiveは、push が正常に適用されたら呼び出されますので、通知等に応用できます。
#!/bin/sh
# /hooks/pre-receive と /hooks/post-receive で同じ結果が得られる
read branch hash_old hash_new
echo $branch # 結果例: refs/heads/master
echo $hash_old # 結果例: aca07435522b6e5ed63481aada5733e421fabbb5
echo $hash_new # 結果例: 90746b18c099aec161434e0c35238db219f8e76e
exit 0
#!/bin/sh
# /hooks/update
echo $1 # 結果例: refs/heads/master
echo $2 # 結果例: aca07435522b6e5ed63481aada5733e421fabbb5
echo $3 # 結果例: 90746b18c099aec161434e0c35238db219f8e76e
exit 0
updateでは、引数に値が入力されますが、pre-receiveとpost-receiveでは (なぜか) 標準入力 (read) で入力が来ます。
1つ目の値は、更新前時点で最新のコミットのハッシュが、2つ目の値は、更新後で最新のコミットのハッシュ、3つ目の値は操作が行われたブランチが入力されます。
pre-receiveとupdateとでは、pre-receiveは 1度の push で 1度だけ実行される点、updateは、更新のかかったブランチ全てに実行される点が異なります。
例えば、branch1とbranch2を更新した後、git push --allとコマンドを実行した場合を考えます。
pre-receiveでは、その時点での操作先ブランチについての値が入力され、実行されます。
updateでは、refs/heads/branch1 refs/heads/branch2それぞれについて値が入力され、更新されたブランチの数実行されます。
GitHooks に使えそうなコマンド集
Git コマンドから UNIX 標準コマンドまで紹介。
(詳しい説明は省略。メモ程度にご覧ください。)
sed grep
テキストの置換や検索等、テキスト処理色々。
(一応書いておくと、) 加えてif thenやtest等、各種シェルスクリプトでよく使われるコマンドも必須です。
git log -n 1
コミット履歴のうち、最新のコミット 1つのみを表示。
1をその他の数字にすれば、その数字の数だけコミットを表示。
git log -n 1 <HASH>
コミット履歴のうち、<HASH>と一致するハッシュを持つコミットの情報を表示。
git status -s
git statusの結果をシンプル表示します。
Add や Modified 等を示す英数字とファイル名を各 1行ずつ表示。
行数をカウントすれば、変更のあったファイル数を得られます。
git rev-parse --short <HASH>
Git のコミットのハッシュ<HASH>を短縮したものを表示。
rev-parseコマンドは、他にも色々な情報の取得に使えます。