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

Question

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

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

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

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

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

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

Answer 1

Совершайте рано и совершайте часто.

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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