Можете ли вы порекомендовать хороший шаблон сообщения / рекомендации для обеспечения соблюдения в компании? [закрыто]

В Git можно установить и применить хороший шаблон коммита.

Можете ли вы порекомендовать (желательно с аргументацией) хороший шаблон фиксации / руководящие принципы для применения в компании?

я использую

[Abc]: Message.

С помощью Add, Mod (ify), Ref (actoring), Fix, Rem (ove) и Rea (dability) легко извлечь лог-файл.

Пример :

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

Если у меня больше строки, сначала я сортирую их по наиболее важным.

Мы используем следующее:

[Идентификатор билета в JIRA]: [Сообщение: что было сделано] Например - ABC-123: добавлена ​​возможность настройки презентации для региона.

В этом случае при правильной интеграции вы сможете получить измененные / удаленные / добавленные файлы в вашем трекере. Тем не менее, имейте в виду, что вы должны предотвратить что-то вроде ABC-123: Done или ABC-123: Исправлено с фильтрами, если это возможно.

Существует одно простое правило - соглашение, которому следуют многие (если не все) SCM и большинство инструментов, работающих с SCM:

Первая строка сообщения фиксации представляет собой краткую сводку, а остальная часть сообщения содержит подробности.

Таким образом, большинство инструментов отображают только первую строку и отображают все сообщение по запросу.

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

Так что, если есть что-то, что нужно применить, я бы сказал, что это максимальная длина первой строки.

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

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

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

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

В Git можно использовать почти все с помощью хитов Git . Проверьте примеры в .git / hooks для идей.

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

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

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

Мы используем шаблон, содержащий

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

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

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

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

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

[ticketId] [ABC] [topicId] [WIP] Сообщение, где:

• ticketId - идентификатор элемента в хранилище задач
• ABC - добавить (функция), исправить (ошибка), str (структура), dep (зависимость) rem (обратная несовместимость / удалить), rea (читабельность), ref (рефакторинг)
• topicId - может быть селектором работы для jenkins и / или имени ветви и / или имени темы для gerrit
• WIP - работа в процессе / или нет (т. Е. Для этого может потребоваться непрерывная интеграция)
• сообщение - деталь модификации

Примеры:
[# 452567] [добавить] [menu_item] новый элемент - гостевая книга
[# 452363] [fix] [banner_top] [WIP] 1024x300 можно использовать сейчас
[# 452363] [fix] [banner_top] 500x200 можно использовать сейчас
[ # 452713] [rem] [page] левое среднее объявление