1

ワークフローには3つの主要なブランチがあります。

TEST（実験的）、RELEASE（次のリリースに進む機能）、およびMASTER（リリースのみ）

RELEASEから機能ブランチを取得し、最初に機能ブランチをTESTにマージし、問題がない場合は、承認された機能ブランチをRELEASEにマージします。

私の問題は、TESTブランチにはこれまでリリースされないコミット/機能が含まれているため、誤って（または意図的に）RELEASEまたはMASTERにマージされたくないということです。

ローカルリポジトリでのマージを防ぐことは不可能または実行可能ではないことをどこかで読みましたが、それで問題が解決するとは思いません。

したがって、新しい参照のコミットログにTESTブランチの特定のコミットIDが含まれている場合は、メインリポジトリのMASTERまたはRELEASEブランチ参照が更新されないようにすることをお勧めします（オリジンにプッシュすることにより）。

したがって、TESTブランチに対してのみ特定のコミットを行い、そのコミットIDを記録します。

誰かがマスターまたはリリースブランチにプッシュしたいときはいつでも、そのプッシュが私のrefs / heads/masterまたはrefs/heads/RELEASEを履歴にその不正なコミットIDを含むコミット参照に更新して中止するかどうかを確認します。

私はBASHまたはGITマスターではないので、メインリポジトリに適用できるような更新フックを持っている人はいますか？

4

2 に答える 2

3

これがそのために機能するはずの更新フックです。forbidden/junkまたはのようなタグを付けることで、RELEASEまたはMASTERブランチに許可されるべきではないコミットを指定できますforbidden/debugging。禁止されたコミットが見つかった場合、タグ名が拒否メッセージに含まれます。

refname="$1"
oldrev="$2"
newrev="$3"
case "$refname" in
  refs/heads/RELEASE|refs/heads/MASTER)
    for forbidden in $(git tag -l 'forbidden/*'); do
      if [ $(git merge-base "$forbidden" $newrev) = $(git rev-parse "$forbidden") ]; then
        echo "Push to $refname contains commit $forbidden" >&2
        exit 1
      fi
    done
    ;;
esac
exit 0

複数の問題のコミットを含むブランチがある場合はforbidden、シリーズの最後のコミットだけでなく、最初のコミットのタグを作成する必要があることに注意してください。したがって、、、、およびがすべて禁止されている次のような履歴BがC禁止Dとしてタグ付けされているだけでは、マージされて一緒に持ち込まれるDことを妨げることはありません。EB

A---B----C----D
     \
      ---E
于 2012-11-14T18:14:49.307 に答える
0

この問題は、自動化の問題ではなく、管理の問題として解決する必要があります。問題は、TESTに他の2つのブランチからのコミットの大部分も含まれている可能性が高いことです。そのため、TESTからのコミットを効果的に特定することはできません。たとえば、私たちの環境では、マスターブランチからの新しいコミットで実験ブランチを定期的に更新しています。

何か悪いことがマスターにマージされた場合、問題が解決される前にそれがデプロイされないようにするために、リリースマネージャーとして機能する誰かが必要です。問題は、それ自体が必ずしも悪いマージではありません。問題は、不正なマージを展開することです。

役立つと思われるツールの1つは、コミットの基本的な承認メカニズムを備えたBitbucket.orgです。これは単なる助言ですが、どのコミットが承認され、どのコミットが誤ってマージされた可能性があるかを追跡するのに役立つ場合があります。

于 2012-11-14T15:05:49.523 に答える