4

master各コミットがリモート側でプッシュフックをトリガーするように、機能ブランチのすべてのコミット (たとえば、から始まる) を個別にプッシュする簡単な方法はありますか? これは、最初に失敗したテストを実装してコミットし、次に修正する場合の「テスト優先」シナリオに役立ちます。

できることはわかっていますがgit push sha:remote-ref-name、手動で行うのは面倒です。

4

3 に答える 3

1

@cforbish のコミット リストは、質問者 (および私) が必要だと思うことを実行しませんでした。まだプッシュされていないコミットのリストを、古いものから新しいものへと順に取得します。これは私にとってはうまくいきました（いくつかのことを配線することでここでは省略している彼のスクリプトの一般性を高く評価しています）：

#!/bin/bash

for rev in $(git rev-list --reverse origin/master..HEAD);
do
    git push -f origin ${rev}:master
done
于 2015-07-13T00:14:45.073 に答える
1

これがテスト優先のシナリオに適している理由はよくわかりませんが、一度に 1 つのコミットでビルドをトリガーすると、実際にはビルドが失敗してから成功するということを意味している場合を除きます。

とはいえ、サーバー側のフック スクリプトを改善するだけで、必要なものを得ることができます。post-receiveフック スクリプトは古い sha1 と新しい sha1 の両方を受け取るため、その間のリビジョンのリストを計算できます。

$ git rev-list OLD_SHA1..NEW_SHA1

これには、マージから持ち込まれた個々のコミットも含まれます。ワークフローのためにすでにテストされている可能性があるため、それらを個別にテストする必要がある場合としない場合があります。したがって、次の方法でのみメインラインのコミットに制限できます。

$ git rev-list --first-parent OLD_SHA1..NEW_SHA1

ただし、いくつかのエッジ ケースがあります。

  • ブランチがリベースされる可能性があります。以前のバージョンのブランチに存在していた新しいリベースされたコミットを再テストしますか?

  • ブランチは新しい可能性があります。ただし、ブランチの履歴全体を再テストする必要はありません。すでにテスト済みのものを判断するために、どのブランチを使用しますか? master?

  • ブランチを削除できます。このケースは簡単です...おそらく何もしません。

post-receiveフックで更新された参照を読み取る例を次に示します。

#!/bin/bash

# The current working directory will be in the bare repo being updated.

while read oldrev newrev refname
do
    # Skip deleted branches.
    if [ "$newrev" != "0000000000000000000000000000000000000000"]
    then
      if [ "$oldrev" == "0000000000000000000000000000000000000000"]
      then
          # New branch.  Test all commits in the branch by using master
          # as a base.  If this was master being created, then nothing will
          # get triggered.
          oldrev=$(git merge-base master $newrev)
      fi

      for sha1 in $(git rev-list ${oldrev}..${newrev})
      do
          # Tip off build server for each commit between oldrev and newrev
          tip-off-build-server $sha1
      done
    fi
done

更新されている参照の名前があることに注意してください$refname（これは参照の完全な名前であり、短縮版ではありません）。ビルドサーバーのために何らかの形でそれを変更する必要があるかもしれません。

これはすべて、特定の設定にも依存します。ビルド サーバーが単にリポジトリのブランチをポーリングするだけの場合、一度に複数のコミットをテストすることは避けられません。プッシュでひっくり返されている場合は、スマートにするのにそれほど遠くはありません. ただし、ここでさらにロジックが必要になる場合があります。プッシュに複数のxコミットがある場合、このアプローチを採用したくない場合があります。別のプロジェクトの履歴を取り込むことを想像してください。何千ものコミットになる可能性があり、その場合、すべてを個別にテストしたくない場合があります。ブランチが分岐し、テストが必要なリビジョンを計算するときに、いくつかの問題が発生する場合もあります。これをもう少し徹底的にテストして、目的の動作を示していることを確認してください。

ところで、githooksはスクリプトに何が渡されているかを判断するのに役立ちます。

クライアント側でも個々のプッシュを実行できますが、スクリプトを作成しないとできません。git rev-list上記と同様に、 $newrevローカルブランチの現在のヒントを 使用できます。(または)$oldrevを取る か、以前にブランチをプッシュしたことがある場合。ポイントは、プッシュするコミットのリストを支援するために使用してから、それぞれを個別にプッシュできることです。このアプローチはお勧めしませんが、実行できます。masterdevelop@{upstream}git rev-list

于 2013-10-24T10:12:21.540 に答える