約12人の開発者からなる私のチームは、ローリングリリースモデルでWebアプリケーションを作成します。いくつかの機能セットの準備ができたら、上級開発者によってレビューされ、QAシステムにプッシュされ、次に本番システムにプッシュされます。これは通常、就業日に数回発生します。
現在使用されているVCSはSVNであり、QAと本番システムへのプッシュは、SVNで動作するが、ファイルベースの奇妙な社内展開ツールを使用して行われます（したがって、ファイルXの新しいバージョンをプッシュする必要がある場合はXは、まだプッシュしたくない他の変更セットからの変更をプッシュ解除しました。問題があります）。
Gitに切り替えるための伝道を計画しているので、ワークフローがどのようになるかを上で考えています。バージョン管理されたリリースがないため、頻繁にリンクされる成功したGit分岐モデルのような通常の提案は適用されません。
質問1：ローリングリリース用に最適化された、上記のリンクにあるような、さらなるインスピレーションを得るために見ることができる文書化されたワークフローはありますか？それとも提案しますか？
私は紙の上でワークフローをモデル化しようとしました。これは通常どおり機能ブランチとマスターを使用し、QAサーバーと本番サーバーの状態を反映するブランチがさらにあります。（1つはマスターからそこにマージするだけです。）
私が克服できない問題は、マスター内の何かが何らかの理由でリリース準備ができていない場合です。たとえば、機能ブランチfooが完了したと見なされ、 masterにマージされ、 qaブランチにプッシュされたとします。次に、機能ブランチバーについても同じことが起こります。QAシステムでは、fooが壊れており、さらに開発が必要であることがわかりましたが、barを本番システムにプッシュする準備ができています。しかし、 barを含むがfooを含まないmasterにはコミットがないので、何をプッシュしますか？頭に浮かぶのは、マージコミットを元に戻すことだけです。fooをmasterに変換します。（リンクの後ろで、Linusはマージコミットを元に戻す際のいくつかの問題について説明しています。）
質問2：この問題をよりエレガントに克服する方法はありますか？