ゲートコミット
ゲートコミット、ゲートチェックイン[ 1 ]、または事前テスト済みコミット[ 2 ] は、バージョン管理のメインブランチに変更をコミットすることで、ビルド（および多くの場合、それに関連するテスト）が壊れる可能性を低減するソフトウェア統合パターンです。このパターンは、継続的インテグレーション（CI）サーバーによってサポートされます。 [ 3 ]
ゲートコミットを実行するには、ソフトウェア開発者は、実際の変更を中央の場所にコミットする前に、CIサーバーにゲートコミットをリクエストする必要があります。CIサーバーは、ローカルの変更をマスターブランチのヘッドにマージし、ゲートを構成する検証（ビルドとテスト）を実行します。これにより、開発者は変更を実際にコミットすることなく、変更がビルドに悪影響を与えるかどうかを確認できます。中央の場所へのコミットは、ゲートがクリアされた場合にのみ許可されます。
代替案として、このパターンはバージョン管理における異なるブランチを用いることで実現できます。例えば、GitHubはブランチBへのすべてのコミットを、CIサーバー上で正常にビルドされ、最新の状態（つまり、ブランチBをベースとしているか、リベースとしている）にあるプルリクエストからのマージコミットに強制することができます。[ 4 ]
参照
参考文献
- ^ 「TFSでビルドトリガーを設定する」 Visual Studio . 2016年6月18日閲覧。
- ^ 「事前テスト済み（遅延）コミット - TeamCity 9.x ドキュメント - Confluence」 confluence.jetbrains.com . 2016年11月25日閲覧。
- ^ 「ビルドパターン: ゲートコミット」 。 2014年8月18日閲覧。
- ^ 「必須ステータスチェックの有効化」。GitHubユーザードキュメント。2016年6月18日閲覧。
年（存在する場合）は、最初の安定版リリースの日付を示します。名前がイタリック体で表記されているシステムは、メンテナンスが終了しているか、サポート終了が予定されています。 | ||||||
| ローカルのみ |
|  | ||||
| クライアント・サーバー |
| |||||
| 分散型 |
| |||||
| 概念 | ||||||
