チェックインされたコードに競合マーカーを残す理由はありますか？

Question

競合マーカーを検討してください。例：

<<<<<<< branch blah blah this ======= blah blah that >>>>>>> HEAD

私がこの質問を投稿する動機となった特定のケースでは、責任のあるチームメンバーが上流からブランチへのマージを完了し、場合によってはこれをコメントとして、これまでのことに関する一種のドキュメントとして残しました解決しました。彼はそれをコンパイルされた状態にし、テストに合格したので、あなたが考えるほど悪くはありません。

しかし、本能的に私は本当にこれに異議を唱えましたが、悪魔が私に提唱しているので、なぜ彼がそれをしたのかがわかります。

マージの結果として何が変更されたかを他のチーム開発者に強調するためです。
特定のコードに詳しい方は、コメントで示されている懸念事項に対処できるため、推測する必要がありません。
アップストリームマージは苦痛であり、すべてを完全かつ完全に解決するための時間を正当化するのが難しい場合があるため、半完全なFIXME通知が必要です。これを文書化するためのコメントとして元の競合を使用しないでください。

私の異議は本能的でしたが、合理的に正当化できるようになりたい、または私の立場をより賢く見たいと思っています。誰かが私にいくつかの例または人々がこれをやっている誰かと悪い時間を過ごした経験および/またはそれが悪い習慣である理由を教えてもらえますか（またはあなたは悪魔の擁護者を演じてそれをサポートできます）。

私自身の直接の懸念は、関係のあるファイルの1つを編集していて、変更をプルし、実際の競合が発生し、コメント付きのファイルもプルされている場合、明らかに煩わしいことでした。それで私は確かに非常に厄介なファイルを持っていただろう。幸い、それは起こりませんでした。

Dima · Accepted Answer

これは明らかに間違っています。変更を追跡するのはバージョン管理システムの仕事であり、マージの結果として何が変更されたかを示すのは差分ツールの仕事です。変更内容とその理由を説明するコメントが、コミットログとコード内にあるはずです。ただし、私見、競合マーカーをコメントとして残すことは、死んだコードを残すことと同じです。

Jacek Prucia · Answer

一部のコードがコメント化されているか（これはどういうわけかあなたのケースに似ています）、または実際にはどこにも呼び出されていないメソッドに移動したことで、同様の問題が発生しました。なぜ人々がこれを行うのかと尋ねられたとき、彼らはいくつかのコードブロックがまだ残っているとき、彼らは少し安全だと感じました。最も明白な反論は、それがVCSの仕事であり、彼らの仕事ではないということです。ただし、別の側面もあります。他の誰かが学習または変更を行っているときにコードを読んでいるとき、彼はおそらくそのようなコメントによって傍観されるでしょう。彼は間違いなくそれを読み、おそらくそれがなぜここにあるのか、そしてそれが彼の現在の仕事とどんな可能な相関があるのかを理解するためにおそらく時間を費やすでしょう。競合マーカーは既に解決されている競合の兆候なので、これは確かに時間の無駄です。

wallenborn · Answer

コメントはそこにあるコードを参照する必要があると思います。過去に存在したコード、過去にコードに発生したイベント、または並列のユニバース（別のブランチ）に存在したコードを参照する必要があります。過去。チームメンバーが行った方法でマーカーを残すと、少なくとも3つの問題が発生します。

元のコードはおそらく_blah blah null_のようなものであり、バグレポートでは「nullをそこで使用したり、これまたはそれを使用したりすることはできません」などと報告されていました。したがって、2人が独立してバグを修正し、修正がマージされたときに競合が発生しました。コメントには、問題が何であったか、修正が何であったかが記載されているのではなく、過去のある時点で2つの異なる修正があったことが示されています。それはあまり役に立ちません。 _//blah blah needs a non-null argument_のようなコメントは、少なくとも何が変更されたかを示します（その情報でさえ、バージョン管理システムのコミットコメントからより簡単に利用できます）。
マージされたバージョンは、元の行の1つに見えない場合もあります。たぶんあなたがこれとそれを受け取ることを望むなら、正しい形式はblah blah (this,that)またはもっと複雑なものです。その場合、競合メッセージをコメントとして残すと、後でコードを読み取ろうとする人を混乱させることになります。
ほとんどのバージョン管理システムでは、プロジェクト履歴にアクセスできます。たとえば、Eclipseで（svnを使用して）ファイルを右クリックし、「履歴を表示...」と言ってから、「現在と比較...」と言って、相違点を強調表示する差分ウィンドウを表示できます。相違点のハイライトに実際の相違点が含まれ、それらの周りのコメントが含まれていない場合は、簡単に理解できます。コード内の機能以外のあらゆる変更により、相違点が読みにくくなります。