アジャイルブランチワークフローのためのGitマージ戦略

Question

アジャイルと連携してフィーチャベースで機能をリリースできるようにする新しい分岐ポリシーを採用しており、masterブランチとQAブランチを永続ブランチとしてリリースしています。ナイトリービルドはQAに基づいており、リリースはmasterになります。開発者は各ストーリーのフィーチャーブランチを作成します。すべてのフィーチャブランチはmasterから分岐され、テストのためにQAにマージされ、フィーチャブランチが後でリリースするためにmasterにマージされます。これは、次のシナリオまで、細かいです：

• 開発者A（「ロッド」）、feature/RodsFeatureを作成したいくつかの作業を行い、QAにマージしている（ただし、まだmaster）
• 開発者B（「ジェーン」） feature/JanesFeature作成した、いくつかの作業を行い、今QA
• 競合が今feature/RodsFeature

のロッドのマージによって QAに導入された変更によって引き起こされる、ジェーンのために発生しているマージにマージしようとしています

JaneがQAをバイパスしてfeature/JanesFeatureをmasterにマージすると、feature/RodsFeatureがまだmasterにないため、競合は発生しません。しかし、明白な理由から、JaneはQAにマージする必要があります。この矛盾を解決するために、彼女はRodの変更を自分のフィーチャーブランチに統合し、その矛盾を解決してからマージを実行することができます。彼女がフィーチャーブランチをmasterにマージすると、 QAテストがまだ保留中です。

QAブランチで直接コンフリクトを解決し、後でmasterにマージするためにJaneのフィーチャブランチをそのまま残すことで回避することができます。しかし、これはコードレビューポリシーを破棄します。マージはピアによって承認される必要があります。これにより、ローカルでQAにマージされ、プルリクエストやピアレビューなしでリモートにプッシュされます。

この場合、「ベストプラクティス」とは何でしょうか？

Answer 1

Git Flowをご覧ください。あなたが達成しようとしているものに最も近いものです。

開発者は、機能ブランチをqaブランチ（Git Flowではdevelop）から分岐します。可能であれば（機能が完了しているか、安定した状態になっているか、または電源がオフになっている）、機能を完了して（定期的にQAの最新の状態を取り込みます）、developにマージしてください。

qaブランチとして実行するものは、おそらくGitflowのreleaseブランチです。

マスターへの変更はすぐにdevelopにマージされます。私たちは、機能1と機能2で問題があった

• https://www.atlassian.com/git/tutorials/comparing-workflows/

Answer 2

tl; dr：dev：コードレビューの変更を含む特定の 'タスク'ブランチのプルリクエストを行う分岐を追加します。

私が行ってきたチームプロジェクトの中には、Githubや一部のリポジトリマネージャの "pull要求"を行うブランチがありました。そこでは、上級者が何が変更されたかを見て、その変更がうまく書かれているかどうかを確認します。

Githubのようなオンラインリポジトリのホスト環境では、元のブランチなどを使って変更を表示する明示的なUIを持っています。ブランチを調べた後、seniorデベロッパーはDevブランチに移動して最終的にホストされますqaの環境では、スプリントの終わりまでに見える。