19

私はgitを使用しており、ワークフローをサポートするために次のブランチを設定しています。

  • リリースされたソフトウェアのみを含むリリース、
  • テストグループにリリースされたソフトウェアを含むテスト、
  • 開発は、開発が行われる場所です。
  • some_topic_branch、機能などが追加されます。

トピックブランチはから分岐し、開発にマージされます。テストリリースの準備ができたら、テストは開発にマージされます。テストリリースの本番環境が承認されると、リリースはテストにマージされます。

これはすべてセットアップが簡単ですが、gitの強制オプションについて疑問に思っています。たとえば、リリースブランチでのコミットのみがテストからのマージであり、リリースブランチで直接変更が発生しないようにするポリシーを適用することは可能ですか？

4

4 に答える 4

11

そうですね。でも、あなたはそこに行きたいとは思わない。

Jason が言うように、特定の動作を防ぐために使用できるフックがあります。この場合、pre commit フックを使用して、誰も「git commit」を実行できないようにすることができます。しかし、これにはいくつかの点で問題があります。

  1. さまざまなセキュリティ上の理由から、git フックはリポジトリと一緒に配布されていないため、リポジトリでフックを使用することを人々に強制することはできません。彼らのリポジトリは彼ら自身のものであり、彼らが彼らのリポジトリで何をするかをあなたが決めることではないことを覚えておいてください.
  2. プルまたはマージを実行して競合が発生するとどうなりますか? これらの競合を解決するには、「git commit」を使用できる必要がありますが、これは現在無効になっています。

これは、解決するよりも多くの問題を生み出すだけです。

ただし、これは他の方法で解決できます。これらの原則を適用するワークフローを作成できます。たとえば、テスト ブランチからリリース ブランチへのマージを担当する人物 A がいるとします。この人だけが変更を中央リポジトリにプッシュできるようにした場合 (またはその人のリポジトリが「中央」リポジトリである場合)、彼/彼女はテスト リポジトリのテスト ブランチまたはのテスト ブランチから変更をプルできます。テスター B (想像力を働かせてください)。

ここで重要なのは、変更を相互に伝達する方法を設計することで、ポリシーを強制できることを理解することです。誰もが変更を1 つのリポジトリにプッシュできる必要はありません。まったく、変更をプッシュする必要さえありません。テストの人/人は、開発者が何かをテストする必要があるとすぐに、開発者から変更を取り込むことができます。このようにして、新しい変更を取り込む準備ができたときにテストに決定させることができます。もの。同じ原理。

于 2011-05-31T15:44:11.787 に答える
4

この種のワークフローに関するその他のアイデアについては、Git フローを確認してください。

于 2011-05-31T14:28:03.680 に答える
2

いくつかの git フックを使用して、これを強制できるはずです。

于 2010-11-03T03:05:54.843 に答える
0

最近では、承認の実施のために作成されたフレームワークであるgitoliteが、あらゆる種類のポリシーを導入するのに役立ちます。たとえば、テスターのみが " Testing" ブランチにマージできるようにするなどです。

さらに、gitolite はVREF (「Gitolite 更新フック リポジトリを除外する」で説明) を使用して、gitolite によって管理されるリポジトリにプッシュされるコミットを制御する多くの「更新フック」を定義する可能性を提案します。

ただし、これらのコントロールはすべて「中央」リポジトリ用であり、さまざまな開発者のワークステーションで複製されたすべてのダウンストリーム リポジトリ用ではありません。

于 2012-10-04T13:11:35.157 に答える