version-control - 競合をマージする傾向のない変更を作成するにはどうすればよいですか？

Question

自動マージは完全ではありません。行編集の競合がないからといって、構文の競合がないことを意味するわけではなく、意味の競合がないことを意味するわけでもありません。

競合の少ない変更を作成するための戦略を持っている人はいますか？これはTDDまたは他のアプローチから外れるものですか（確かにTDDはそれらをキャッチするのに役立ちますが、実際には防止します）？

Answer 1

コミットが小さければ小さいほど、マージの競合が発生する可能性は低くなります。大きな問題を抱えている人々は、いつも何日も立ち去って物事に取り組んでいるようで、それからそれらすべてを一度にマージしようとします。

現在、私は2人のチームで作業しており、常に同じコードベースにいます。私たちはそれぞれ個人のブランチで作業し、何かが機能しているときはいつでも共有ブランチに統合します。それは通常1日に数回です。マージの競合が発生することはほとんどありません。発生した場合、それらは非常に簡単です。

だから...リポジトリから最新のコードを頻繁に入手してください。自分のブランチで作業するので、チームの他のメンバーに影響を与えることなく、変更をコミットして他の人の作業をマージできます。次に、変更ができるだけ小さくなるように、独自のコードをできるだけ頻繁に共有ブランチにプッシュします。

また、チームに相談してください。他の誰かが特定のファイルで作業していることがわかっている場合は、その人が作業を開始するまで待ってからジャンプすることをお勧めします。それを助けることができない場合もありますが、コミュニケーションによって、少なくとも複雑なマージを計画することができます。驚いた。

Answer 2

単一責任の原則に違反するクラスは、マージするのが最も困難です。マージが困難なクラスを見つけることは、おそらくより多くの部分の方向に、リファクタリングする必要があることを示しています。

Answer 3

まず、コードベースはモジュール式である必要があります。次に、必要なのはチームの他のメンバーとのコミュニケーションです。誰が何に取り組んでいるのかを誰もが知っている必要があります。内部APIに変更がある場合は、チーム全体に明確にする必要があります。

また、コミットする前に、常に最後のバージョンをフェッチし、複雑なマージが必要な場合は、ローカルで実行してください。

これは実際には人間の問題であり、技術的な問題ではありません。ソース管理は適切な通信チャネルを置き換えません。プロジェクトマネージャーは、すべての変更を把握している必要があります。また、変更が複数の人にまたがる場合は、プロジェクトマネージャーが理解する必要があります。

また、共通の意味が必要です。:)

もちろん、単体テストは、マージ時に発生する可能性のある最もとらえどころのないバグを見つけるのに大いに役立ちます。

Answer 4

仲間の開発者に相談し、可能な限り同じコードブロックの同期編集を避けるようにしてください。十分にモジュール化されたアーキテクチャ（小さなクラス、分離された機能）を持つことで、これはほぼ常に可能になります。

衝突が発生した場合は、テストされていないコードの単体テストを数分間作成するように切り替えることで、衝突を解決することがよくあります。