12

シナリオは次のとおりです。開発者のチームは、コミットが受け入れられる前に、すべての新しいコードが定義されたコーディング標準に一致し、すべての単体テストに合格していることを確認したいと考えています。すべてのテストは専用のテスト マシンで実行する必要があり、git サーバーを変更するアクセス権がないため、各開発マシンでローカル コミット フックを使用して行う必要があります。

仕様はかなり厳密ですが (たとえば、Windows や Subversion に切り替えていません)、これは現実世界の問題であるため、ほぼ適合するソリューションがあればある程度の柔軟性があります。

  • Git と *nix を使用しています。
  • テスト スイートを実行するには、更新されたコードを別のサーバーに送信する必要があります。
  • コーディング標準に確実に一致するように、変更されたファイルのリストを提供する必要があります。
  • これはかなり大きなコードベースであるため、コードベースの同一のコピーを確保するために必要な最小限の情報を送信する必要があります。
  • テストが失敗した場合は、エラーとともにメッセージを表示し、コミットをブロックする必要があります。
  • 開発チームを信頼しており、オプションを使用してテストをバイパスしても問題ないと仮定し--no-verifyます。

質問:テスト サーバーをローカル環境と同期させてテストを実行する最善の方法は何ですか? 新しいコミットの git パッチとハッシュ間の一致のようなものはありますか? Git を完全にスキップして、rsync だけを実行しますか? まったく別の何か？

2013 年 8 月 7 日更新:リモート リポジトリについて言及したことで自分自身を撃ちました。重要なのは、コードが共有/リモート リポジトリにプッシュされるのをブロックすることではなく、ローカル コミットが行われないようにすることです。これがベスト プラクティスと見なされるかどうかは、この場合の実際のポイントではありません。これは、この正確な機能を必要とする開発者の小さなチームに固有のものだからです。問題は、目標を達成するための最善の方法についてです。

4

6 に答える 6

12

ローカル コミット フックは、ここで必要なものではありません。

「gitサーバーを変更するアクセス権がないため、各開発マシンでローカルコミットフックを使用してこれを行う必要がある」という要件は完全に偽物です。完全に制御できる「テストリモート」である別のリポジトリをいつでもセットアップできます（制御できないgitサーバーと同期します）。

このテスト リモートを設定したら、フックを追加して、任意のプッシュでテストを実行できます。git push test-remote my-branchテスト結果を取得するために入力する労力はごくわずかです。

Git との継続的な統合

また、Jenkins、gitlabなどもチェックしてください...

2013 年 8 月 7 日以降の更新:

したがって、コミットを防ぐために、リモートサーバーでいくつかの「テスト」を実行する必要があります。コミット自体の内容に基づいて防止したい場合は、pre-commitフックを使用します。変更されたファイルのリストを取得する方法については、この質問を参照してください。 これらの変更されたファイルを取得したら、scpまたはを使用してそれらをリモート サーバーに取得しrsync、 でテスト コマンドを実行できますssh。

コミット メッセージを確認する必要がある場合は、commit-msgフックを使用します。

フックに関する優れたチュートリアルは次のとおりです: http://git-scm.com/book/en/Customizing-Git-Git-Hooks

また、それが悪い考えである可能性があるいくつかの理由についても言及しています。

特定のポリシーを強制するためによく使用されますが、これらのスクリプトはクローン中に転送されないことに注意することが重要です。サーバー側でポリシーを適用して、ポリシーに準拠しないコミットのプッシュを拒否できますが、クライアント側でこれらのスクリプトを使用するかどうかは完全に開発者次第です。したがって、これらは開発者を支援するためのスクリプトであり、開発者がいつでも上書きまたは変更できますが、セットアップと保守を行う必要があります。

于 2013-08-03T05:17:08.337 に答える
12

簡潔な答え：

しないでください

長い答え:

いくつかの奇妙なローカル フックのためにコミットを実行できないのは、私には奇妙に思えます。コミットを作成する (つまり、変更を保存する) ことと、このコミットを公開することを分離する必要があります。

pre-receiveあなたが言及した git サーバーにルールを適用するフックを持つことは完全に合理的ですが、開発者のリポジトリにとっては劇的です。コミットする前にコードを磨くために。

これは逆効果です: リポジトリに何かをコミットしなければならず、誰もが自分のエラーや悪いコーディング スタイルなどを見ることができた、悪い昔に戻ったような気分になるでしょう。DVCS が提供する自由を失うことになります。安価な分岐、ローカル ヒストリー、本番コードの中央レポを維持することなどです。

ローカルコミットを行うときは、何も強制しません。

于 2013-08-06T14:44:58.610 に答える
1

他の人が提案したように中間サーバーをセットアップした後、pre-receiveフックをセットアップして、着信コミットに対してスクリプトを実行し、コーディング標準に正規化します。多くの場合、コーディング標準は、コンピューターで実施可能な規則によって定義されます。開発者に、単純な bash スクリプトまたは開発者のためにそれを実行できるものがある場合に、空白をあちこち微調整させないでください。pushまた、それを行うスクリプトがある場合、中間リポジトリごとに自動的に実行できるのに、なぜ開発者に手動で実行させるのでしょうか。

于 2013-08-06T16:00:22.843 に答える
0

次のような Makefile を作成します。

  1. 現在のファイルをテスト サーバーにコピーします。

  2. 単体テストの出力を検索します。

2.1. 異常がなければ「git commit」を実行

2.2 異常がある場合は、エラーをエコーし​​ます。

Makefile を使用してコンパイルとコミットを行うことは天の恵みです。コミットする前に、複雑な書式設定とファイルのクリーンアップを自動化できます。

編集：

もちろん、できることは Makefile だけではありません。Ant/Bash/その他のスクリプト言語でこれを行うことができます。

于 2013-08-08T20:37:42.293 に答える