コードレビューのためにブランチがgitに依存関係を持っている場合のワークフローとプロセス
Gitを操作するためのかなり一般的なワークフローは次のとおりです。
- フォークマスター
- ブランチで変更/機能の追加を行う
- ブランチとマスターのプルリクエストを作成します
- プルリクエストのマージ（コードレビュー、自動テストなどの後）
これを別のフォークと並行して実行することもできます。おそらく、FeatureBを追加し、同時にFeatureAにパッチ修正を加えている場合、両方ともマスターブランチに基づいて2つの別々のブランチを持つことができます。
これは、独立した部分をより簡単に処理できる確立されたプロジェクトがある場合にうまく機能します。ただし、確立されていないプロジェクトがある場合（おそらく、それは新しいプロジェクトであるか、ひどく脆弱である）、FeatureAを持っていて、FeatureAをベースにしてFeatureBを持っている可能性があります。
コードレビュープロセスがある場合、これは次のようなものがあることを意味します。
- FeatureAのコードを書く
- FeatureAのPRを作成する
- FeatureAがマスターにマージされるのを待ちます（必要に応じてFeatureAを更新します）
- FeatureBのコードを書く
- FeatureBのPRを作成する
ターンアラウンドタイムによっては、ステップ（3）に時間がかかる場合があります。そのため、ステップ（4）から開始し、（3）/（4）を同時に実行する可能性があります。 （5）が起こる準備ができているかもしれません。
問題は、レビューされていない機能に依存する追加のコードを記述していることですORは、コードレビューがFeatureAを処理するまで何も機能していません。 PRが統合されます。
これを解決するいくつかの可能性があります（FeatureAのブランチに対してPRを実行し、FeatureAのPRが続行するのを待ち、FeatureA PRを更新し続けます）。
依存するプルリクエストに関連する問題を管理するための優れたワークフローは何ですか？
依存関係に関連するリスクを比較検討する必要がありますが、できるだけ早くBに取り組み、必要に応じてAで行われた変更をBに伝播する余裕があると思います。
- Aのプルリクエストが受け入れられれば（コードビルドなど）、すべて問題ありません。平均して、あなたはそのケースに頻繁に遭遇するはずです。
- そうでなければ、何が起こる可能性がありますか？最悪の場合、Aは完全に壊れているため、削除する必要があります。つまり、Bをさらに深く修正するか、削除する必要があります。しかし、より現実的には、Aのマイナーなものを編集して修正する必要があります。そうであれば、ブランチBにマージできます。
ブランチAが頻繁に変更される場合は、ブランチBをベースにすることはお勧めできません。