gitは、特定のマージに競合があること、および競合とは何かをどのように判断しますか？
私の推測では、次のようになります。マージされる2つのコミットに共通の親コミットがあり、両方とも親が持っていたものから行Xを変更した場合、それは競合です。
私の理解を複雑にしているのは：
誰かがこれがどのように機能するかを説明できますか、または機能するリンクを教えてもらえますか？
基本的に、gitを使用すると、すべてのマージが競合し、各ファイルの3つのバージョン、各ブランチのバージョン、およびベースを含むインデックスが残ります。このインデックスでは、さまざまなリゾルバーが実行され、個々のファイルごとに問題の解決方法を決定できます。
最初の段階は些細なリゾルバーで、変更されていないファイル、一方のブランチがファイルを変更したのに他方が変更しなかった場合、または両方のブランチに同じ新しいバージョンのファイルが含まれている場合などを処理します。
その後、残りのケースを調べるのはプラグインです。一方のブランチで個々の変更（diffなど）を識別し、それらをもう一方のブランチに適用しようとしてテキストファイルを処理するプラグインがあります。それが機能しない場合は、競合マーカーの配置にフォールバックします。この時点で、独自のマージツールを簡単にフックできます。たとえば、整形式に違反することなくXMLファイルをマージする方法を知っているツールや、インタラクティブな編集とサイドバイを可能にするグラフィカルユーザーインターフェイスを提供するツールを作成できます。 -側面図（たとえば、kdiff3がそれを行います）。
したがって、競合の表示は実際には使用されるプラグインの問題です。テキストファイルのデフォルトのプラグインは、CVSが使用したのと同じスタイルを使用します。これは、人とツールがそれに慣れており、競合マーカーはほとんどすべてのプログラミング言語で既知の構文エラーであるためです。
マージアルゴリズムにはGitに特別なものはないと思います。これは、いくつかの戦略（デフォルト：recurse、resolve、またはoctopus）で使用できる古典的な3ウェイマージアルゴリズム（Codevilleのものではありません）です。結果は、ここで説明するかなり単純なマージプロセスです。
その後、視覚化の必要性はすべて、サードパーティのマージ/差分ツールに委任されます。
このページHOW CONFLICTS ARE PRESENTEDの段落を参照してください。
LE：競合のケースやファイルの競合マーカーに関する実際のドキュメントはありません。ここのコメントでバッシングされているので、競合状態を実現するためにgitが従う戦略に近いソースコードのポインターを次に示します。 。ファイルmerge-recursive.c、文字列を検索し"CONFLICTます。そうすることで、次のような実際に少数の紛争事例があることが簡単にわかります。
あなたが私に尋ねるなら、はい、それらは文書化され、明確に指摘されるべきです、しかしそれらは何もすることが残っていないのでソースを調べます..しかし誰かが本当にここから拾い上げて素晴らしい文書を作成しそしてそれをに送ることができますgitプロジェクト。
@Wim Coenenはい、それはマージ戦略にも依存しますが、競合がどのように提示されるかによって、より多くの洞察が得られます。そうすれば、私に尋ねればマージ戦略も読むことができますが、それでも疑問が残ります。