ブランチからの複数のプルリクエストの処理
現在のワークフローでは、Sprintブランチを作成してから、開発者がユーザーストーリー番号を持つFeatureブランチを作成しています。ストーリーが完了すると、このFeatureブランチはプルリクエストによってSprintブランチにマージされ、コードレビューが行われます。コードレビューが完了したら、別のプルリクエストをDevelopブランチに送り、そこでオンサイトコードレビューを行います。
問題は、複数のチームがSprintからDevelopブランチへのプルリクエストを作成している場合、最新のプルリクエストが承認されるとパイプライン化されたプルリクエストが承認されることです（これは予期される動作ですか？）
オンサイトコーディネーターは、Sprint to Developブランチからのプルリクエスト情報を使用して、本番環境にリリースする必要がある変更を追跡します。
しかし、自分のプルリクエストはパイプライン内の他のプルリクエストが承認されると自動的に承認されるため、発生したプルリクエストのステータスを取得できません。プルリクエストのマージコミットを見つけるには、開発ブランチのコミット履歴に移動する必要があります。
私のプルリクエストを追跡する簡単な方法はありますか？
スプリントからリリースブランチへのプルリクエストを表示すると、多くの変更が含まれる可能性があります。これらの変更は、以前のプルリクエストですでに確認されています。現在のスプリントの変更を組み込むためにanotherコードレビューを要求することは冗長に聞こえます。スプリントブランチを開発ブランチにマージして、それをプッシュするだけです。プロジェクト全体でスプリントごとに1つのマージのみを実行している場合、マージはいずれにせよ早送りマージである必要があり、リスクは低くなります。
本当の問題は「スプリント」ブランチです。コメントで、スプリントブランチは、機能またはタスクが完了したスプリントを追跡するために作成されると述べました。これは、Gitが設計されたものではなく、バージョン管理システムでもありません。作業項目の追跡はバージョン管理の問題ではありません。これには、Jira、Azure DevOps、Rational Team Concertなどの別のツールを使用する必要があります。ポストイットノートやExcelスプレッドシートでも、スプリントにブランチを使用するよりもうまく機能します。
コミットとスプリントの関連付けは、そのコミットに関連付けられたタイムスタンプを使用して行う必要があります。あなたのスプリントは、暦年を明確に定義された開始日と終了日で小さな断片に分割する必要があります。コミットがスプリントの開始日と終了日に該当する場合、そのスプリントでコミットされました。ただし、ここでも、作業項目のステータスは、バージョン管理ではなく、他の場所で追跡する必要があります。