Есть ли у вас какие-либо политики коммитов?

Question

Вчера мой начальник объявил о новой политике коммитов для регистрации в репозитории. Эта политика действительна для коммитов в голову / ствол и ветви.
Сообщение фиксации должно содержать следующие элементы:

• Причина (идентификатор ошибки, идентификатор проекта или нефункциональное изменение)
• Фамилия рецензента

После коммита мы также должны создать запись в блоге изменений в нашей CMS.

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

Есть ли у вас какие-либо правила коммитов, которым вы должны следовать?

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

Answer 1

У нас есть ряд политик, которые применяются через внутренний плагин для Visual Studio. Мы проверяем, что код компилируется и что модульные тесты были успешно выполнены. На данный момент мы также проверяем покрытие кода и выпускаем предупреждения для кода, в котором недостаточно тестов. Мы также проводим различные проверки согласованности и проверяем наличие соответствующей задачи в нашей системе управления изменениями, чтобы обеспечить возможность отслеживания всех изменений.

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

Answer 2

Фиксация рано и частая фиксация.

На самом деле мы используем / trunk как разработку и теги для ветвления различных выпусков. В /branches идут только структурные навязчивые изменения.

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

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

Не сказать, что я не люблю интеграцию в SVN: - Мы используем больше возможностей автоматизированных скриптов nant для создания релизов, которые разветвляют их в теги / - svn props фактически хранит наши номера версий: p. - подключить скрипты для уведомлений по электронной почте и регистрации сообщений (отлично подходит для копирования, вставки заметок о выпуске).

Answer 3

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

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

Answer 4

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

Answer 5

Рецензент кажется бессмысленным по причинам, которые вы упомянули, потому что не все должны проверяться другими.

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

Answer 6

У нас есть ветки для каждой выпущенной основной версии программного обеспечения, которая все еще активно поддерживается. Для входа в любую из этих веток требуется идентификатор ошибки - это обеспечивается scmbug , который не только проверяет, что перед комментарием стоит префикс идентификатора ошибки, но также ищет эту ошибку в базе данных ошибок, убедитесь, что он назначен для коммиттера, и, возможно, проверьте другие критерии (например, что поле «fix in branch» - это ветвь, для которой выполняется фиксация).

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

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

Answer 7

Мое сообщение о фиксации содержит краткое описание того, что я реализовал или изменил в классах.

Номер ошибки и дополнительные описания, которые я поместил в комментариях над новым кодом. Идентификаторы внутри сообщений фиксации, которые мы помещаем при объединении изменений в размеченную ветку.

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

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

Подумайте о том, что вам иногда приходится понимать код, который вы реализовали 2 года назад. И тогда вы довольны сообщениями о фиксации, которые не похожи на «Обновление после отладки».