これに沿って、Git リポジトリの事前テスト済みのコミット構造があり、一種の自動化された統合マネージャーです。
ただし、ブランチの削除には問題があります。ブランチは開発者のローカル リポジトリから削除でき、その変更は開発者によって個人のリポジトリにプッシュされる可能性がありますが、その変更は「グリーン」または「ブランチが削除されたときにビルド サーバーがビルドをトリガーしないためです。
開発者の個人用リポジトリからすべてのブランチを取得し、「グリーン」リポジトリからすべてのブランチを取得するスクリプトを作成すると (これには他の多くの開発者からのブランチが含まれることに注意してください)、
git push origin :BranchName
個人用ではない「グリーン」に存在する各ブランチについて、開発者が個人用リポジトリで削除したブランチは削除されますが、他のすべては残りますか?
これは機能しますか？これよりも良い解決策はありますか？
システムが参照の削除をキャッチしてビルドをトリガーできるかどうかはわかりませんが、CIインスタンスは開発者のリモート個人リポジトリからプルしているgit remote prune originため、CI側で削除されたブランチを削除するために使用する必要があります個人用リモートリポジトリ（originがdevリモートリポジトリのリモート名であると想定します。これは、そこから複製されたためです）
CIがグリーンリポジトリにプッシュしているとき、リモート側のブランチのサブセットを現在のものと比較し、削除されたブランチを見つける機能があります。したがって、CI側では、プッシュするたびにそのようなことを行うことができます。
git branch -a | grep {green_repo_remote_name}
ローカルブランチのリストと比較してください。
git branch
実行します
git push {green_repo_remote_name} :branch_name_that_exists_only_in_green_repo
アップデート：
以下のコメントによると、上記のアプローチは他の開発者ブランチをグリーンリポジトリから削除するようです。私の悪い。私が見ているように、それを解決するための2つのアプローチがあります。
I.グリーンリポジトリでの開発ブランチの作成を停止し、CIを使用して実際に変更を統合します。
devパーソナルリポジトリからの変更時に、CIはこの変更をチェックアウトし、一般的に知られている統合ブランチをグリーンリポジトリからプルし、devブランチをそれにマージしてコンパイルする必要があります。成功した場合は、変更をグリーンリポジトリにプッシュバックします
II。CIリポジトリをグリーンリポジトリのリモートとして登録し、グリーンリポジトリ側の受信後フックで遊んでトリガーしgit remote prune *ます。これにより、各リモートのCIリポジトリから削除されたすべてのブランチが効果的に削除されます。
お役に立てば幸いです。