コードがGitFlowを使用して別のブランチからマージされるのを待つことで開発者がブロックされた
私たちのチームはFogBugz＆Kiln/MercurialからJira＆Stash/Gitに切り替えました。分岐にはGitフローモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするとき、通常はStashを使用してレビューアを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻します）。
私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで共同作業しているときに、機能ケースの計画と内訳が最善であっても、相互依存するコードで作業している場合、別のブランチでは、一方の開発者が他方をブロックすることになります。
開発中はお互いの枝の間を引っ張ってみました。また、各開発者が複数のブランチからプルして、開発中に統合をテストできるローカル統合ブランチを作成することも試みました。最後に、これは今のところ私たちにとってはおそらく最もうまくいくようですが、少しオーバーヘッドが大きいため、機能ブランチからすぐに統合ブランチを作成しようとしました。 （機能ブランチの外の）サブタスクブランチがプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。次に、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルすることができます。これにより、依存しているブランチがコードレビューをパスするのを誰かが待つのを防ぎます。
私はこれが必ずしもGitの問題ではないことを知っています。それは、複数のブランチで相互依存するコードで作業し、独自の作業プロセスと文化と混合していることに関係しています。開発用の厳密なコードレビューポリシー（真の統合ブランチ）がない場合、開発者1はマージして、開発者2が開発元からプルすることができます。もう1つの問題は、機能をQAに引き渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。つまり、フロントエンド開発者1がバックエンド開発者2のブランチから直接プルしている場合でも、行ってください。バックエンドデベロッパー2が終了し、プルリクエストがコードレビューに1週間置かれている場合、フロントエンドデベロッパー2はコードレビューアーができないため、技術的にプルリクエスト/コードレビューを作成できません。バックエンドの開発者2のコードがまだ開発にマージされていないため、テストしてください。
結論として、これらのインスタンスでは、実行するルートに応じて、並列ではなく逐次的なアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。
最後に触れておきますが、コードのレビューとファイナライズが行われていないブランチ間でコードを共有することで、まだ他の人のベータコードを使用しています。ある程度は避けられないと思いますし、ある程度は喜んで受け入れるつもりです。
問題は、バックエンド開発とフロントエンド開発の間のタスクの分離が厳しすぎることにあるかもしれません。
フロントエンドの開発者が新しいAPIを必要とする場合、レイアウトを検証するために、バックエンドでダミーのAPI（たとえば、常に同じ値を返す）を作成できるようにすることはできませんか？次に、その部分的な実装をスタブでコミットします。2回目は、バックエンド開発者が実際の機能を実装します。
依存関係を解消することで、フローが改善され、ボトルネックとして機能する単一のタスクを待機しているすべてを停止する必要がなくなります。
あなたの問題：開発者Aがマスターから分岐し、開発者Bがマスターから分岐し、どちらも密接に関連する機能に取り組んでいます。避けられない競合のためにマスターブランチへのマージが難しいという避けられない事実は、すべての人を妨げています。
これが予測できる場合、AとBは最初に共通ブランチを作成し、次にこの共通ブランチからの個別の作業の各ブランチを作成し、個別の作業のそれぞれを共通ブランチにマージします。これで、競合のないブランチが大幅に増えました。統合が簡単です。
開発者1が機能Aで作業し、開発者2が機能Aに依存する機能Bで作業を終了した場合、回避策はありません-機能Bのマージは保留中です。機能Aなしでテストすることはできません。機能Aがさらに進歩すると機能Bが変更される可能性があるため、まだレビューする意味はありません。
ただし、これは開発者2が待機しているという意味ではありません。開発者2は機能Cの作業を開始し、機能Aが完了すると、機能Bのレビュー修正サイクルに戻ることができます。コンテキストの切り替えが最適ではないことは知っていますが、機能Aの完了までにかかる時間はおそらく数日で測定されるため、実際にはそうではありませんそれ悪い（「ゾーン」からそれらを引き出していないため15分のサイドタスク）
状況を改善するためにできることの1つは、開発サイクルを短縮する方法をよく検討することです。
開発者が別の開発者からの機能を待っている場合、最初の開発者の作業の一部が、機能全体の前にレビューと統合を経てブロックを解放する方法はありますか？
統合サイクルを継続するために、機能をより小さな作業単位に分割する方法はありますか？
また、統合にはどのくらい時間がかかりますか？ビルドまたは統合の方向転換が長いと、キュー全体が遅くなる可能性があります。キューがより早く解放されるように、ビルド時間を短縮するためにできることがあるかどうかを確認してください。