Пометка сообщений коммита и наборов изменений - PullRequest
Новая
       60

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

7 голосов
/ 05 января 2012

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

Для меня «тег» - это что-то вроде:

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

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

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

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

Справочная информация:

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

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

Ответы [ 3 ]

8 голосов
/ 05 января 2012

Мне нравятся следующие теги: 

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 of test foo".

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

3 голосов
/ 23 февраля 2015

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

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

Теги Typo3:

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

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

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

  • [!!!]: критическое изменение. После этого патча что-то работает не так, как раньше, и пользователю / администратору / разработчику расширения придется что-то менять. Должно происходить только на «хозяине».
  • [WIP]: работа в процессе. Этот флаг будет удален, как только будет доступна окончательная версия изменения. Изменения, помеченные как WIP, никогда не объединяются.
  • [БЕЗОПАСНОСТЬ]: визуализирует, что изменение устраняет проблему безопасности. Этот тег используется командой безопасности, если вы обнаружили проблемы с безопасностью, пожалуйста, всегда следуйте, сначала свяжитесь с командой безопасности!

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

  • [BUGFIX] Бросить исключения HttpStatus в tslib_fe
  • [BUGFIX] [БЕЗОПАСНОСТЬ] Уязвимость SQL-инъекции в подготовленных выражениях
  • [FEATURE] [CONF] Добавить опцию, чтобы скрыть окно поиска BE в моде списка
  • [!!!] [FEATURE] Переместить расширенное редактирование внешнего интерфейса в TER
  • [!!!] [TASK] Удалить t3lib_sqlengine
  • [!!!] [API] Удалить устаревший метод redirect () из t3lib_userAuth
  • [API] Создание иерархии исключений для исключений состояния HTTP
1 голос
/ 06 января 2012

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

...