Пометка сообщений и наборов сообщений

Question

Я ищу решение, чтобы отметить изменения в сообщениях фиксации.

Для меня "тегов" что-то вроде:

• код очистить
• пользователя видны изменения
• изменяет структуру базы данных (ALTER TABLE)
• изменение документации

До сих пор я использую SVN, но хочу переключиться на git. Если бы было стандартно, многие инструменты, такие как trac, redmine, ... могли бы использовать это.

Я хочу, чтобы ответить на такие вопросы:

• Если я обновлю систему, какие изменения открыты для клиента, или это просто обновление разработки В?
• Изменена ли схема базы данных между двумя версиями?

фон:

До сих пор я использую в унисон, чтобы синхронизировать между DEV, TEST и системой PROD. Но унисон ничего не знает об управлении версиями (это SVN у мумификации). Я хочу переключиться на git. И я хочу быстро увидеть, каковы изменения.

Пример: Я хочу видеть изменения между TEST и PROD. Я не хочу видеть изменения исходного кода, но сообщения фиксации. Но иногда до 100 коммитов. Здесь я хочу фильтр, чтобы исключить неважные изменения.

Answer 1

Я хотел бы использовать следующие теги:

ADD adding new feature 
FIX a bug 
DOC documentation only 
REF refactoring that doesn't include any changes in features 
FMT formatting only (spacing...) 
MAK repository related changes (e.g., changes in the ignore list) 
TEST related to test code only. 

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

Я использую эти теги с svn и git и до сих пор нашел их очень удобными.

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

Мне также нравится комбинировать теги в одном сообщении с сообщением, где это необходимо. Например, «TEST DOC setup test foo».

С дополнительным тегом DB для базы данных вы можете легко отслеживать изменения, связанные с базой данных.

Answer 2

Я предпочитаю назначать каждый набор изменений проблеме в моем трекер-проблеме. Используя известные трекеры проблемы, такие как jira, можно выбрать проблему, которая разрешена в наборе изменений. После выбора проблемы описание проблемы автоматически помещается в сообщение набора изменений. Их можно отслеживать в будущем, а также сообщать о них в своем трекер-проблеме.

Answer 3

Большую часть времени я использую систему тегов из Typo3: http://wiki.typo3.org/CommitMessage_Format_(Git)

Он использует теги в сообщения фиксации, как это: [TAG] Short message Конечно, я всегда выскочит в номер выпуска для отслеживания ошибок. Мы используем JIRA, так что будет что-то вроде этого: [TAG] JIRA-123 Short message

TYPO3 теги:

Возможные теги:

• [FEATURE]: Новая функция (также небольшие дополнения). Скорее всего, это будет добавленная функция, но она также может быть удалена. Это может произойти только в ветке «master» v4, поскольку в старых ветвях не допускается никаких новых функций. Исключения из этого должны обсуждаться в каждом конкретном случае с соответствующими менеджерами выпуска.
• [BUGFIX]: исправление ошибки.
• [ЗАДАЧА]: Все, что не относится к вышеуказанным категориям, например. очистка стиля кодирования.
• [API]: API был изменен, методы или классы были добавлены или удалены; были изменены сигнатуры методов или типы возвращаемых данных. Это относится только к публичному API TYPO3.

Кроме того другие флаги могут быть добавлены при определенных обстоятельствах:

• [!!!]: Разорвать изменения. После этого патча что-то работает по-другому, чем раньше, и разработчику user/admin/extension придется что-то изменить. Должно произойти только на «хозяине».
• [WIP]: работа продолжается. Этот флаг будет удален после того, как будет доступна окончательная версия изменения. Изменения, отмеченные как WIP, никогда не сливаются.
• [SECURITY]: Визуализирует, что изменения устраняют проблему безопасности. Этот тег используется командой безопасности, если вы обнаружили проблемы с безопасностью, всегда следите за тем, чтобы вступить в контакт с командой безопасности в первую очередь!

описание Пример темы:

• [BUGFIX] Throw HttpStatusExceptions в tslib_fe
• [ИСПРАВЛЕНИЕ] [БЕЗОПАСНОСТЬ] SQL Injection уязвимости в подготовленных заявлений
• [FEATURE] [CONF] Добавить возможность скрыть поле поиска BE в списке мод
• [!!!] [FEATURE] Переместить расширенный интерфейс редактирования в TER
• [!!!] [ЗАДАЧА] Удалить t3lib_sqlengine
• [!!!] [API] Удалить устаревший метод перенаправления() из t3lib_userauth
• [API] Создание иерархии исключений для исключения HTTP Status