1

開発者が変更をフェッチしてプッシュする中央の Git リポジトリがあります。デフォルトのマスター ブランチに変更を加えます。当社の継続的インテグレーション (CI) ツールは、このデフォルトのマスター ブランチからアーティファクトをビルドし、テストしたいものを「UAT」ブランチに昇格させる責任を負うエンティティです (これは実際には、ビルドマスターの人がプロモーションを行う CI ツールの Web ページ)。CI ツールは、コードを UAT から "Production" ブランチにプロモートする役割も担います。UAT ブランチと Production ブランチの目的は、UAT と Production にプロモートされたものを取得することです。UAT ブランチでは開発は行われず、開発/リリース イテレーションは非常に高速 (1 週間のイテレーション) であるため、プロダクションにはまれな「ホット フィックス」の形での「開発」のみが含まれます。

簡単にできるのであれば、誰かが誤って UAT ブランチと Production ブランチに直接開発変更を加えるのを防ぐためのコントロールを入れたいと考えています。1 つの考えは、中央サーバーにフックを設けて、CI ツール ユーザーだけが UAT と本番環境を変更できるようにすることです。また、マスター ブランチのみを含む開発者が使用する中央レポと、UAT および Production ブランチを含む 2 つ目のレポを用意できると考えました。CI ツールは両方のリポジトリと通信します。開発からリポジトリへの変更を確認し、2 番目のリポジトリを使用して UAT ブランチと Production ブランチへの昇格を行います。

これは人々が通常行うことですか (開発とプロモーションの目的で別々のリポジトリを使用しますか?)、サーバー フック アプローチよりも優れているでしょうか?

4

2 に答える 2

2

あなたがサブスクライブする目的のためには、フックを介した不正なコミットとマージを防ぐことが最善の方法だと思います. どのリモコンを追跡しているかを特に気にする必要はありません。また、常に前後に簡単にマージしてしまう可能性もあります。

于 2012-08-05T18:28:36.120 に答える
0

git リポジトリのクローン作成は安価でセットアップも簡単だと思います。CI ユーザー/ビルド マスターが何かを UAT/本番環境に昇格できる場合、変更を別のリポジトリにプッシュしてみませんか? おそらく、Linux カーネル開発モデルのようなものです。すべての変更は、開発者によってチェックインされ、CI ユーザーによってテストされた後、承認され、リリース リポジトリにプッシュ (おそらく署名) されています。

特定の領域でのコミットを特定の人に制限することができたとしても、分散ツールでそれを行う方法はないと思います。私はオープン リポジトリが好きで、おそらく特定の用途には他の専用リポジトリを使用しています。Git はすべてを保持し、他のリポジトリにプッシュして情報を失うことはありません。したがって、作成者は常に作成者のままであり、コミッターのみが変更されます。

これは、多くの情報を含む非常に優れた記事です: What git branching models really work

于 2012-08-05T19:42:27.113 に答える