Почему регистрация / комментирование является обязательным полем в некоторых системах контроля версий?

Question

В Perforce (по крайней мере, в GUI) требуется комментарий о регистрации / коммите. (Я не верю, что они требуются в Git или Subversion.) Большинство разработчиков, которые работают со мной, просто заполняют его последними / обновленными / и т.д. Раньше я писал содержательные описания, но около 20 комментариев в день с такими вещами, как «заменить изображение». «Измененное написание слова« franhcise »становится действительно раздражающим. Кроме того, большинство изменений можно быстро увидеть в Diff.

Сначала я думал, что просто ленивый, но я склонен даже не смотреть на них при просмотре кода других людей. Я лучше пойду прямо на Diff. Я один? Нужны ли комментарии для хорошей идеи?

Answer 1

Вы всегда должны оставлять хорошие комментарии. Не обязательно описывать что вы изменили, если только это не большой набор изменений со слишком большим количеством отвлекающих мелких деталей ... но всегда, всегда , опишите почему вы сделали изменить (возможно, ссылку на элемент отслеживания ошибок, если таковой имеется).

Когда я смотрю на ваш дифференциал год спустя, после осознания того, что он внес небольшую ошибку, мне нужно знать, почему было сделано изменение - если я не могу найти вескую причину, я просто собираюсь откатись и прокляни свои ленивые пути ...; -)

Answer 2

Значимые комментарии служат нескольким целям:

• Если вы ищете конкретное изменение в истории версий, они позволяют вам быстро просмотреть историю файла (например: «Эй, я знаю, что мы исправили ошибку, связанную с мерцанием этого виджета где-то в марте в прошлом году. Вы помните, что это было за исправление? ").

• Они побуждают вас совершать атомарные коммиты. Если вы заканчиваете регистрацию с общими комментариями, это, вероятно, означает, что вы делаете слишком много вещей одновременно.

• Как упоминалось ранее, они сообщают вам, почему что-то меняется. Конечно, diff может сказать вам, например, как изменился расчет налога для такого-то элемента. Но это не скажет вам, что это потому, что закон XYZ для налогообложения изменился.

• Они облегчают написание заметок о выпуске или эквивалентной документации.

Answer 3

Возможно, немного другой точки зрения:

Если вы хотите просмотреть ВСЕ изменения за год или со времени последнего выпуска - хотите ли вы просмотреть все различия, или вы хотели бы видеть хороший комментарий о коммите и ссылку на дефект / элемент проблемы?

Answer 4

Как уже обсуждалось в комментариях к ответу Shog9 , применение комментария на уровне инструмента не обязательно помогает поддерживать ленивых в очереди, потому что требование слишком простое обойти (как уже упоминалось в вопросе: просто наберите "latest" / "updated" / etc или даже "sfakjs; d", что, вероятно, более опасно, чем пустая строка).

Однако тот факт, что инструмент требует его , может служить напоминанием для обычно прилежного разработчика, который случайно собирается совершить коммит без объяснения причин. Если он делает это хотя бы один раз, то мы находимся в плюсе (то есть требование является выгодным), потому что обычно функциональность не имеет никакого значения - хорошие парни все равно пишут комментарии, тогда как плохие парни всегда могут обойти требования, независимо от того, какие технические барьеры вы устанавливаете. (Хотите ли вы оставить их занятыми, это другой вопрос, конечно.)

Answer 5

Написание значимого комментария занимает около 30 секунд, так что просто прекратите и сделайте это.

Answer 6

Если вы делаете 20 проверок в день, вы, вероятно, регистрируетесь слишком часто. Сгруппируйте все мелкие исправления опечаток в единую регистрацию с комментарием «исправлены различные опечатки».

Answer 7

В основном потому, что они не предназначены для использования в коммитах после изменения атрибута css и т. Д., А скорее после внесения более значимых изменений / исправлений. Но комментарии в любом случае очень полезны.