未完成の機能ブランチとコードレビューからのマージ
Gitフローワークフローを使用していますが、長寿命の機能ブランチがある場合があります。もちろん、別の機能ブランチが完成し、開発ブランチにマージされたら、開発ブランチから機能ブランチにマージできます。ただし、他の機能ブランチから直接マージすること、つまり、終了する前にマージすることは良い考えですか？レビューアが同じコミットを複数回レビューする可能性があり、変更が物議を醸している場合は、誰も気付かないうちに異なるレビューアからの正反対のコメントが表示される可能性があるため、コードレビューの重複と潜在的な競合が発生しませんか？または、同じ論理的な変更が2つの機能ブランチで分岐し、2つのわずかに異なる変更になる可能性があります。
理想的には、ストーリーを独立させたいが、たとえ理論的に独立している場合でも、あるレベルの低レベルのリファクタリングや修正作業など、一部の部分的な変更がしばしば別のブランチで再利用したい場合があるブランチ。
私たちはそのような状況で何をすることを提案しますか？変更を手動でコピーして貼り付けることは役に立たないようです。実際、問題を隠すだけのようです。もちろん、コードレビューやデモを優先したり、ストーリーを小さくしたりすることで、この問題を回避することはできますが、それでもこの問題は時々発生すると思います。
これは、すべてのソース管理システムに共通の問題です。これはコミュニケーションの問題であり、グローバルに大規模な変更を簡単に行えるため、さらに悪化する可能性があります。最も一般的な解決策の概要を説明しました。
- 機能ブランチで行われる作業を小さくして、メインブランチとの統合や比較が容易になるようにします。
- できるだけ早く機能ブランチを統合することを優先します。ブランチが古くなるのを許可しないでください。
他のいくつかのアイデア：
- 最も重要なブランチを除いて、どのブランチでも「低レベルのリファクタリングと修正作業」を許可しないでください。
- 機能の変更を比較するときは、分岐元の元のソースとのみ比較してください。統合するために作業をやり直す必要があるかもしれません。
- 広範囲にわたるグローバルな変更を行う人は、他のすべてのブランチで作業している他のすべての人々とコミュニケーションを取る必要があります。これらのタイプの変更を行う前に、すべてのブランチをマージするようにしてください。それが完了するまで、さらに分岐をフリーズします。