ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2020-05-23. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

記事のバージョン: Enterprise Server 2.17

pre-receiveフックについて

pre-receive フックは GitHub Enterprise Server アプライアンス上で動作するスクリプトで、品質チェックを実装するために利用できます。

ここには以下の内容があります:

プッシュが行われると、各スクリプトは分離された環境で実行され、プッシュの内容についてのチェックを実行できます。 このスクリプトの終了ステータスが0ならプッシュは受け付けられ、0以外なら拒否されることになります。

利用のシナリオ

pre-receiveフックは、ビジネスルールを満たしたり、規制の遵守を強制したり、一般的なミスを避けたりするために利用してください。

pre-receiveフックの利用方法の例:

  • 正当なチケット番号を含めたり、一定以上の長さでなければならなかったりといった特定のパターンやフォーマットに伴うコミットメッセージを要求する。
  • すべてのプッシュを拒否する事でブランチまたはリポジトリをロックする。
  • キーワード、パターン、ファイルタイプをブロックすることによって、センシティブなデータがリポジトリに追加されないようにする。
  • PRの作者が自身の変更をマージしないようにする。

パフォーマンスとワークフローへの影響

開発者と開発者のワークフローへの影響は大きくなりうるので、注意深く検討することが必要です。 ビジネス上の要求に基づき、思慮深く実装されたpre-receiveフックは、全体として組織に最大のメリットをもたらします。

pre-receiveフックはGitHub Enterprise Server インスタンスのパフォーマンスに意図しない影響をもたらすことがあり、慎重に実装され、レビューされなければなりません。

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください