Чи є виправдання для того, щоб залишити маркери конфлікту у зареєстрованому коді?

Розгляньте маркери конфлікту. тобто:

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

У конкретному випадку, який мотивував мене поставити це запитання, відповідальний член групи щойно завершив злиття від верхнього потоку до нашої гілки, а в деяких випадках залишив це як коментарі, як якусь документацію щодо того, що щойно було вирішено. Він залишив це у складеному стані, проходив тести, тож це не так вже й погано, як ви могли б подумати.

Інстинктивно, хоча я дійсно заперечував проти цього, проте, будучи захисниками чортів для себе, я можу зрозуміти, чому він міг це зробити:

• оскільки це підкреслює іншим розробникам команди те, що змінилося в результаті злиття.
• тому що ті, хто більш досвідчений у конкретних фрагментах коду, можуть потім вирішити проблеми, проілюстровані коментарями, так що йому не доведеться вгадувати.
• тому що злиття вгору за течією є правильним болем, і це може бути важко виправдати час, щоб вирішити все добре і повністю, тому потрібне деяке напівповне повідомлення FIXME, тож чому б не використовувати оригінальний конфлікт як коментар для документування цього.

Моє заперечення було інстинктивним, але я хотів би мати змогу обґрунтувати це раціонально або зрозуміти свою позицію більш розумно. Хто-небудь може надати мені кілька прикладів чи навіть досвіду, коли люди погано проводили час, коли хтось це робив, та / або причини, чому це погана практика (або ви можете грати в захисника диявола і підтримувати це).

Моє власне негайне занепокоєння полягало в тому, що це, очевидно, було би прикро, якби я редагував один із відповідних файлів, витягував зміни, отримував реальні конфлікти, але також тягнув коментовані. Тоді б у мене був справді безладний файл. На щастя, цього не сталося.

Це явно неправильно. Завдання системи контролю версій - це відслідковувати зміни, і це робота різних інструментів, щоб показати, що змінилося в результаті злиття. У журналі фіксації та, можливо, у коді має бути коментар із поясненням того, що було змінено та чому. Однак IMHO, залишати маркери конфлікту в коментарях, це те саме, що залишати мертвий код навколо.

У мене були подібні проблеми з тим, що якийсь код був або прокоментований (що якимось чином подібний до вашого випадку), або перейшов до методу, який насправді нікуди не викликається. На запитання, чому люди роблять це, у відповідь було те, що вони почуваються трохи безпечніше, коли в них є ще якийсь блок коду. Найбільш очевидний аргумент - це робота VCS, а не їхня робота. Однак є й інший аспект. Коли хтось ще читає код під час навчання чи внесення змін, він, ймовірно, буде відслідковуватися таким коментарем. Він обов'язково прочитає його і, можливо, витратить деякий час, щоб зрозуміти, чому він тут і яке можливе співвідношення це має з його нинішньою роботою. Оскільки маркер конфлікту є ознакою конфлікту, який уже вирішено, це точно марна трата часу.

Я думаю, що коментарі повинні стосуватися коду, який там є, а не до коду, який там був у минулому, ні до подій, що траплялися з кодом колись у минулому, ні до коду, який існував у паралельній всесвіті (іншої гілки) в минуле. Залишаючи маркери так, як це робив ваш член команди, створює принаймні три проблеми:

1. Оригінальний код, ймовірно, був чимось на кшталт blah blah null, і у звіті про помилку сказано: "Не можна використовувати нульові, використовуйте те чи інше чи будь-що інше". Тож двоє людей самостійно виправили помилку, і коли виправлення були об’єднані, виник конфлікт. Тепер коментар документує не те, в чому була проблема, ані те, що виправлено виправленням, а лише те, що в певний момент минулого було два різні виправлення. Це не дуже корисно. У //blah blah needs a non-null argumentтакому коментарі хоча б вказується, що змінилося (і навіть ця інформація легше доступна з коментаря до коментаря системи управління версіями).
2. Злита версія може навіть не виглядати як одна з оригінальних ліній. Можливо, якщо ви хочете, щоб благ взяв це і те, правильна форма є blah blah (this,that)або навіть щось складніше. У такому випадку залишення конфліктного повідомлення у коментарі неодмінно заплутає тих, хто намагається прочитати код згодом.
3. Більшість систем управління версіями надають вам доступ до історії проекту. Наприклад, я можу клацнути правою кнопкою миші на файл у затемненні (із svn), сказати "Показати історію ...", а потім сказати "Порівняти поточне зі ..." та отримати розрізне вікно, яке висвітлює відмінності. Ця інформація є способом простіше бачити, якщо підсвічування різниці містять фактичні відмінності, а не зауваження навколо них. Кожен біт нефункціональної зміни коду ускладнює читання.

Наскільки дратівливі маркери конфліктів у зареєстрованому коді?

Так дратує.