ソース管理分岐の戦略

Question

私たちは、仕事場で使用するための最良のソースコントロール分岐戦略を決定しようとしています。 GITバックエンドに接続されたVSOフロントエンドを使用します。 DEV、QA、STAGE、PRODの4つのデータベース環境があります。私たちは多くのチームが、多くの進行中のデータベースクリーンアップ作業（プライマリとフォーリンキーの追加、カラムの設定を無効にするなど）に加えて、お互いを跳躍するさまざまな機能に取り組んでいます。

私の考えはそれぞれのデータベース環境を反映する4つの永続ブランチ（各データベース環境ごとに1つ）を維持します。新しい機能に取り組んでいるチームはすべてDevから分岐し、その時点で作業が完了して永続的なDEVブランチにマージされます。作業がQAに進む準備ができたら、QAにマージされます.STAGEに移動する準備ができた時点でSTAGEにマージされます。機能ブランチを必要とせずに変更セットとしてフローすることができますが、潜在的に破損している変更はすべて機能ブランチとして機能する必要があります。

誰でもこの戦略を使用しましたか？それは動作しましたか？ 推奨できる分岐モデルがありますか？

Answer 1

誰も答えることができなかったので、自分の答えを使って更新を行います。最初に説明したように、この分岐戦略を多かれ少なかれ使用することになります。主な違いは、PRODブランチがマスターと呼ばれ、フィーチャーブランチがDEVではなくマスターから分岐することです。

これは、マスター/ PRODブランチがDEVよりも安定していると考えられるためです。私がDEVからうまく分岐した以前の環境は、単一のリリース・トレインでした。フィーチャーはここで互いに飛び交うことが期待されるので、私たちはそれを行うことはできません。

また、すべての開発はフィーチャーブランチで行う必要があります。ただし、GITプッシュをVSOチケットにリンクするメカニズムでは、機能がブランチで実行される必要があるため、VSO GITプラグインの制限が原因です。