私はかなりの数年にわたって機能分岐を行い、多くのブランチと混乱して悪夢をマージした後、ブランチング戦略に関する優れたリソースを探していました。フィーチャーブランチは、どの機能をリリースすべきかについてきわめてきめ細かくリリースを管理する上で、優れたアイソレーションをもたらしました。しかし、彼らが提起した問題（多くの支店、合併の紛争）は、彼らが与えた利益よりもはるかに大きかった。トランクベースの開発提案が必要
私たちはバックエンドでOracleデータベース（5000個のオブジェクトを使用）を使用しています。また、同じ製品のさまざまな分野で複数のチームが作業しています。私たちはTFS（DVCSなし）でVisual Studioを使用しています。
私たちが作成するブランチが多いほど、問題の別のセットであるブランチ（各ブランチ - 1つのdbインスタンス）の機能テストで適切な分離が必要なデータベースインスタンスが増えます。
私たちはスクラムを採用しており、リリースサイクル（年4回）とCIビルドに適合する分岐モデルを探しています。私たちは5回の通常のスプリントと1回の強化スプリントを各リリースで行う予定です。モデルの分岐機能から
は、私たちは以下のように分岐し、非常に簡単に私達の分岐モデルを作り直し -
開発ブランチは（トランクベース開発のための）私たちの「トランク」として活躍し、すべての開発されました（すべてのチーム）がこのブランチにコミットしています（四半期ごとにリリース）。テスターはこのブランチでテストを行い、CIサーバー（Jenkins）は毎日このブランチをビルドしています。私たちはいくつかの理由でしばしば使用される "最終リリースの真実の単一のソース"として安全のためにいつでも清潔なMAINが必要です。
メンテナンスブランチは、私たちのバグ修正ブランチ（修正プログラム）であり、年に数回リリースされます（四半期ごとのリリースに関係なく）。私たちは、メインブランチを「きれいな」メインブランチにしたいと思っているので、メインブランチで直接作業しないことを好みます。私たちは、 "手動" /機能テストを実行しなくても、コードをMainに移動させたくありません。バグ修正リリースが完了すると、保守 - >メイン - >開発のコードがマージされ、バグ修正が開発に統合されます。
メンテナンスブランチでバグ修正を継続し、メンテナンスから解放し、変更をメイン（および開発）にマージするため、TBDで提案されているように、通常、リリースブランチは必要ありません。 「Last release」のみを維持し、以前のリリースの修正が必要な場合は、MainのLabelsから古いリリースブランチを作成します。
トランクベースの開発を将来問題が生じる程度に修正しましたか？あなたの提案は何ですか？
は参照してください：
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723