gitflowワークフローでプルリクエストを処理するためのワークフロー（リリースはめったにありません）？

Question

私たちの以前のワークフローはgitflowと似ており、すべてがマスターから分岐しています。マスターは常にプロダクションを反映しています。リリースが準備されているとき、フィーチャブランチはマスターにマージされ、異なるフィーチャ間の競合が修正され、リリース用のタグが作成され、マスターにプッシュされます。

ここで、プルリクエストをこのワークフローに統合したいが、ブランチの開発者は依然としてコンフリクトの修正を担当するようにしたい。アイデアはまだマスターから分岐してから、次のリリースに入る新しいコードであるreleaseXという新しいブランチにプルリクエストを行います。

問題は、新機能と他の機能の間でreleaseXに競合が発生した場合、どのように解決するのですか？ github自体のマージを行うことは受け入れられません。releaseXをフィーチャーブランチにマージすることは、関連しないフィーチャーを引き出すことになり、フィーチャーがまったく生産に入らないようにするために難しくなります。

最後に、mergeのためのブランチを作成しました。これはresolution/releaseX_my_beautiful_featureのようなものです。

（ここでは、代わりにgitflowのモデル（）のようなgithubflowのより以下、連続展開とリリースの本当の概念で、私たちのために最善の解決策ではありません。）

君たちは何のワークフローを採​​用しませんプルリクエストとリリースの両方を使用する場合

Answer 1

@ckrusek氏によると、Atlasssianにはさまざまな種類のワークフローに関する素晴らしいドキュメントがあります。 gitflowについて+リクエストを引くことは、彼らが推薦する何ワークフローです：

• 枝がオフプルリクエストが
• 枝がオフの開発リリース（分岐の命名規則を開発するん
• 機能を開発特長：リリース - *またはリリース/ *）。リリースブランチはリリースを準備するためだけに使用され、開発中でない機能は次のリリースサイクルまで延期されます。
• マージリリースブランチマスターへと
• メンテナンス/ホットフィックスの枝を開発
• メンテナンス/ホットフィックスの枝がマスターにマージし、もちろん

を開発マスターを分岐し、への道はまだありません関連していない機能を機能ブランチに混在させないでください。

基本的にプルリクエストのワークフローはより頻繁なリリースを意味し、これらを処理するために、必要に応じて本番ではあまりテストされていない機能をオフにするために機能フラグを設定する必要があります。このモデルが私たちにもたらすのは、リリースの概念とそれを管理する方法を組み込んだワークフローです。