チェックインコードに競合マーカーを残すことの正当性はありますか?


14

競合マーカーを検討してください。すなわち:

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

この質問を投稿する動機となった特定のケースでは、担当のチームメンバーがアップストリームからブランチへのマージを完了したばかりで、場合によっては、これらをコメントとして、今までの内容に関する一種のドキュメントとして残していました解決しました。彼はそれをコンパイルされた状態のままにして、テストに合格したので、あなたが思うほど悪くはありません。

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

  • マージの結果として変更されたものを他のチーム開発者に強調するためです。
  • 特定のコードに精通している人は、コメントが示す懸念に対処できるため、推測する必要がありません。
  • アップストリームマージは適切な痛みであり、すべてを適切かつ完全に解決するための時間を正当化するのが難しい可能性があるため、いくつかの半完全なFIXME通知が必要です。

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

私自身の当面の懸念は、関係するファイルの1つを編集し、変更を取得し、実際の競合を取得したが、コメントされたファイルも取得した場合、明らかに迷惑になることでした。そうすれば、本当に非常に面倒なファイルになっていたでしょう。幸いなことにそれは起こりませんでした。


1
これはどのバージョン管理システムですか?
c69

これらは誤って残っていたのですか?誰かが差分を表示して、競合をマージせずに保存した可能性があります。これは以前にSmartSVNで発生するのを見たことがあります
CamelBlues

1
ギット。実際のVCSが関連しているとは感じなかったため、タグ付けしませんでした。それらは、いくつかのファイルで意図的にチェックインされました。私は、偶然が一度か二度許されることに同意します。
ベネディクト

「関係するファイルの1つを編集して、変更をプルし、実際の競合を取得したが、コメント付きのファイルも取得した場合、実際には非常に乱雑なファイルになっていたでしょう。」のようなコメントとほとんど同等に聞こえます// MatrixFrog 10/25/2011: Updated this function to fix bug #1234。そのようなものを見たら、「何?それgit blameは何のためだ!」
MatrixFrog

回答:


27

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


5

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


4

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

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

-1

チェックインコードの競合マーカーはどの程度面倒ですか?

とても迷惑です。


1
申し訳ありませんが、この答えは実際には何も追加しません。せいぜいコメントだったはずです。
アダムリア
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.