頻繁な展開とブランチの同期を維持

Question

私の会社では、機能ブランチが稼動する準備ができているときはいつでも、つまり待つ必要はありません。この目的のために、私は、デベロッパー/ gitflowプロセスと思い付いてきました：

プロセスはそうのように動作します：

1. 開発者の枝を離れ、「解放」の分岐と作品フィーチャーブランチ上で
2. 作業中に、開発者はdevのローカルテストをマージすることができます。ステージングに似ていますが、QAはこの環境には触れません。
3. すると、ローカルに開発者テストと作業を完了し、彼らは私たちのstagingブランチにマージしてreleaseブランチにプル要求を発行します。 [緑色の行番号1]
4. stagingブランチに移行すると、ステージングサーバーは自動的に更新およびQAテストを取得します。 [Green line＃2]
5. QAが承認した場合、Pull Requestを受け入れ、テスト済みのものはすべてreleaseブランチになります。 [緑色の点線]
6. とすぐrelease分岐が変化するにつれて、我々はmaster（製造）のブランチにマージしてデプロイを行います。
7. 私の質問：プロダクションに展開した後、productionをstagingとdevにマージしますか？ [レッドライン]

私の関心は、バック下向きproductionをマージするとき、このプロセスは、コードの競合の多くを引き起こすということです。特に、QA - > dev - > QAから何度も移動しているステージングに何かがある場合。

Answer 1

あり、ノイズの多くは、この流れの中だと、私の懸念は、Git Flowは公称実現するもの過度に複雑だということです。一般的に、私のアドバイスは、可能な限り、この流れを簡素化することです - あなたは別の「ステージング」の分岐が必要な場合は、それを作成する - 一般的には：

• 生産対応コードがマスターに住んでいます。
• デベロッパーはマスターの基本作業をオフにします。彼らは機能ブランチをローカルででテストすることができます。そうでない場合は、後でなく早く修正する必要があります。
• QAテストを必要とする機能ブランチはステージングにプッシュされます。理想的には、QAがより多くを処理することに同意しない限り、一度に1つの機能しか存在しません。
• ステージングが満足のいくものであることがテストされたら、それがマスターに統合され、プロダクションにリリースされます。 で正確同時に準備ができている複数の特徴枝の発生の可能性は、それが唯一のこれまでのテストだということに何のあいまいさは、QA（と存在しないように、この方法でのリリースサイクルを簡素化し、稀であることを考えると

一度に1つの機能ブランチ）は、多くのことを単純化します。