開発ブランチをユーザーストーリーブランチにマージする必要がありますか？
比較的単純なバージョン管理プロセスがあります：masterブランチ、dev（別名インテグレーション）ブランチ、およびすべてのユーザーストーリーの個々のブランチ。
Devからチェックアウトし、新しいユーザーストーリーの開始時に新しいブランチに分岐し、終了したら、devブランチに再度マージします。
新しいブランチでストーリーを開発しているときに、devブランチから最新の変更をプルして、それらの変更をユーザーストーリーのブランチにマージするべきではないという意見があります。
なぜそれが悪いのですか？最新の変更をdevからブランチにプルしたら、ストーリーが完全に終了したら、ブランチをdevにマージしますか？
開発ブランチから最新の変更をプルダウンしてから、それらの変更をユーザーストーリーのブランチにマージしないでください。
これは、次の3つの状況のいずれかが原因である可能性があります。
- 潜在的なマージ競合を2回以上調整したくない「遅延」開発者
- Gitマージの方法を理解していない開発者
- モジュール化が不十分なため、他の人が積極的に取り組んでいるコードに触れなければ、誰も作業できないコードベース
おそらく最初のことですが、それは怠惰の問題です。アクティブな開発ブランチがある場合、機能を複数回プルする必要があり、1日に複数回プルする可能性があります。解決策は、小さなマージの競合を頻繁に解決することは、最後に大規模なマージを行うよりもはるか簡単であることを認識しています。
開発者がgitマージを恐れている場合、なんらかの理由で、ひどいハックをしているだけかもしれません。完全な開示：gitの最初の経験では何をしているのかまったくわかりませんでした（現在は何をしているのか）。あなたのチームがgitの動作について同様にナイーブである場合、彼らは必死でこれを行っている可能性があります。
そして最後に、コードベースが根本的な原因である場合、運が悪い場合があります。この種の状況では、常にコードに重大な変更が加えられるため、ローカルを更新し続けることは困難です。リファクタリングが唯一の方法かもしれません。
最終的には、しかし、あなたの開発者がそれをしたいwhyを理解してください。これは、一般的に言えば、これを行うための練習をするのを楽にします。
私のルールは、マージの競合がある場合、ブランチをdevブランチにマージしないことです。論理的な結果として、devブランチを機能ブランチにマージする必要がありますbefore機能ブランチをdevにマージします。
実用的な観点から：devをブランチにマージするか、ブランチをdevにマージするかにかかわらず、結果はまったく同じです。最初にdevをブランチにマージする場合、ブランチをdevにマージすることは簡単なので、これは追加の労力がゼロです。しかし、何かがうまくいかない場合はどうなりますか？マージは競合がない可能性がありますが、問題を引き起こします。これがブランチでのみ発生し、全員に影響を及ぼさない場合は、はるかに良くなります。または競合があります。競合を解決し、発生した可能性のある問題を解決してから、全員がこれに対処する必要があります。
したがって、最初にdevをブランチにマージすると、（十分に注意して）devへのマージがスムーズに行われ、良好な結果が得られることが確実になります。
履歴の角度を別にして（特に、私たちのチームはBitbucketを使用していないため、その点について話すことができないため）、QA /テストの角度を検討する必要があるかもしれません。
当社では、通常の状況下で、QAが機能ブランチの機能の初期テストを行いますbeforeマージされて開発されます。それらは、自動化された回帰とRC回帰を介して、「すべてがサンドボックスでうまく機能する」検証を実行します。私たちは、これを彼らが単独でテストできるようにするための最良のアプローチだと思いました。他の開発者がコードをチェックインして開発し、コードの動作に影響を与え、機能ブランチにマージされた場合、この「分離」に影響を与える可能性があります。
それは完璧ではなく、おそらく私たちの組織/故障/ユーザーストーリーまたは機能の計画について何かを述べていますが、私は脱線します:)
つまり、QAに渡す前に、機能ブランチとソースブランチの間のプルリクエストにマージの競合があることに気付いた場合、will進んでそれらの競合を解決します（ソースをマージすることによって）機能ブランチに分岐）、QAが作業を何度もテストすることを回避します（特に厄介な競合シナリオで）。