プルリクエストとテストの適切な順序は何ですか？
適切な開発ワークフローをセットアップしたいと考えています。マスター（リリースブランチ）と開発（ワーキングブランチ）の2つのメインブランチがあります。プルリクエストを適切に使用したい。これを行う方法は2つあります。
最初の1つ：
- 機能の新しいブランチを作成します。
- 機能を実装します。
- マージしてブランチを開発します。
- テスト開発ブランチ。
- すべてが機能することを確認します。
- マスターブランチにプルリクエストを作成します。
- プルリクエストをマージします。
ステップ4と7はステップ1に戻ることができます。
2つ目：
- 機能の新しいブランチを作成します。
- 機能を実装します。
- 開発ブランチにプルリクエストを作成します。
- プルリクエストをマージします。
- テスト開発ブランチ。
- すべてが機能することを確認します。
- マージはマスターに発展します。
ステップ4と6はステップ1に戻ることができます。
どちらがいいですか？それとも、私が説明したより良い方法がありますか？
チームメンバーは、開発者、テスター、レビュー担当者の3人です。
最初のアプローチの問題は、機能が共有リポジトリに到達する前に、開発者のdevelopブランチを経由する必要があることです。これは、開発者が多くの議論、レビュー、承認、変更を必要とする大きくて重要な機能のプルリクエストを投稿した場合、そのdevelopブランチにまとめられ、投稿できないことを意味しますその大きなPRに関連する他の人のアクション/決定を待つ間、小さなプルリクエスト。
基本的に、ローカルのdevelopブランチは、各開発者にとってブロッキングボトルネックになります。
2番目のアプローチの問題は、機能がテストされることですafter機能は共有リポジトリのdevelopブランチにマージされます。これは、修正されるまで全員のプロジェクトを台無しにする悪いコードがそこにある可能性があることを意味します。また、修正するのが難しすぎるため、または設計全体を台無しにしないと修正できないために機能を延期または中止する場合は、共有リポジトリのブランチの履歴を変更する必要があります。これはとても楽しいことではありません。行う...
基本的に、shared（！）developブランチはチーム全体（!!）のブロッキングボトルネックになります。
だから-私はこれらの問題を回避する3番目のアプローチを提案します：
- 機能の新しいブランチを作成します。
- 機能を実装します。
- テスト機能ブランチ。
- 開発ブランチにプルリクエストを作成します。
- プルリクエストをマージします。
- すべてが機能することを確認します。
- マージはマスターに発展します。
このように、ブロッキングパイプは機能ブランチです。必要な数だけ持つことができるため、ボトルネックにはなりません。
最初のアプローチ（「確認する」）と2番目のアプローチ（「確認する」）のどちらを使用するかは、チームの設定と組織に依存すると私は言います。
多くの場合、緊密に連携して作業しているチームメンバーの小さなグループ（多くの場合、物理的に同じ場所にいるが、常にではない）は、最初のアプローチを好む。
お互いをよく知らず、異なる時間と時間数で作業する可能性のある、広く分散している人々のチームは、中央の権限をより制御できる2番目のアプローチを好むかもしれません。