Какую информацию должен содержать комментарий к файлу SVN / Versioned? - PullRequest
9 голосов
/ 25 марта 2010

Мне любопытно, какой контент должен быть в комментируемом файле комментария. Должно ли оно описывать в целом то, что изменилось (например, «Экран виджетов был изменен для отображения только активных виджетов»), или оно должно быть более конкретным (например, «В условие where добавлено предложение where запроса fetchWidget для получения по умолчанию только активных виджетов») «)

Насколько атомным должен быть один коммит? Просто файл, содержащий обновленный запрос в одном коммите (например, «Обновлен экран виджетов, чтобы отображать только активные виджеты по умолчанию»), или если это и некоторые другие изменения + изменения интерфейса на экране делят тот же коммит с более общим описанием как («Обновлен экран виджетов: A) отображать только активные виджеты по умолчанию B) Добавлена ​​кнопка для отображения неактивных виджетов»)

Я вижу, что комментарии коммитов подрывной деятельности используются совсем по-другому, и мне было интересно, с чем другие добились успеха. Некоторые комментарии так же кратки, как «обновленные файлы», в то время как другие имеют много абзацев, а другие отформатированы таким образом, что их можно запрашивать и связывать с какой-либо внешней системой, такой как JIRA.

Раньше я очень описывал причину изменений, а также конкретные технические изменения. В последнее время я уменьшал количество и просто давал общий комментарий «Это то, что я изменил на этой странице».

Ответы [ 7 ]

9 голосов
/ 25 марта 2010

Некоторые рекомендации:

  • не пишите вещи, которые система VC уже отслеживает автоматически: какие файлы, сколько строк, когда, кто внес изменения ...
  • напишите, какова была цель изменения: «добавить поддержку UTF-8 в теги ID3»
  • если вы обнаружите, что цель неясна или множественна, вам, вероятно, лучше сделать несколько коммитов. Линус Торвальдс может написать "различные исправления повсюду"; остальные из нас не должны брать его в качестве примера.
  • если у вас есть какая-либо система отслеживания, которая присваивает уникальные идентификаторы проблемам или запросам функций, обязательно пометьте комментарий этим идентификатором.
5 голосов
/ 25 марта 2010

это должно кратко объяснить, что содержит коммит. Это должно включать номер заявки для исправления ошибки или улучшения. Лучший совет, который я когда-либо слышал о написании комментариев, - это «Код, как будто следующий парень, который будет поддерживать ваш код, - это маньяк-убийца, который знает, где вы живете». Это одинаково подходит для комментирования.

4 голосов
/ 25 марта 2010

Полезные комментарии - это те, которые добавляют полезную информацию, которую нелегко извлечь из самих изменений. Изучение различий покажет, что изменилось, поэтому комментарий к коммиту должен сосредоточиться на объяснении, ПОЧЕМУ изменения были сделаны:

  • Исправлен сбой из-за разыменования нулевого указателя (идентификатор ошибки 234).

  • Добавлена ​​команда на отключение от сервера (запрос функции 22).

  • Исправлен код для будущих изменений.

Еще один полезный вид комментариев - это тот, который суммирует общую цель большего набора изменений:

  • Добавлена ​​поддержка, позволяющая пользователю переключать виджет.
3 голосов
/ 25 марта 2010

Если вы используете систему отслеживания ошибок, лучше всего включить ошибку / усовершенствование #, над которым вы работаете, которое относится к изменению. Много раз вы просто будете переписывать, что в этом описании ошибки в любом случае.

3 голосов
/ 25 марта 2010

Лично я стараюсь сделать краткое изложение того, что я изменил и / или добавил. Что-то, что напомнит мне: «О да, это [вероятно], где я добавил это дополнительное правило к бизнес-объекту». Потому что я всегда могу запустить "diff", чтобы увидеть, что конкретно изменилось.

2 голосов
/ 25 марта 2010

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

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

1 голос
/ 25 марта 2010

Одна вещь, которая помогает мне, когда я думаю о том, что писать / что не писать, заключается в том, что в конечном итоге станет возможным составление внутренних технических замечаний к выпуску из комментариев фиксации.

Мне также очень полезно устанавливать теги в комментариях к коммитам, например #doc, #typo, #refactor, ...

Я бы не стал слишком описывать при фиксации - причины того или иного действия должны быть в документации или в комментариях к коду IMO.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...