стратегия для извлечения сообщений из наиболее полезных фиксаций к CHANGELOG

Question

Потребности на этот вопрос заключается в

• есть список изменений для менеджеров/клиентов, которые:
  • действительно включает «Пусть пользователи имеют дополнительные адреса»
  • не включает в себя «Исправлена ​​ошибка, при которой адреса были переписаны из-за X»
• избежать того, чтобы просмотреть полный журнал История, чтобы найти наиболее важные фиксации (чаще всего назад несовместимые) для каждой сборки
• сделать это как легко читать как типичные игровые журнал изменения («Неподвижные проблемы баланса: X» и «Графический драйвер Y вынесено игра медленно ")

Сегодня мы используем флаги фиксации сообщений такие как

Add|Ref|Rem|Fix: <msg> для обычного коммита.

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

CL-Add: feature X (CL = изменений), а затем разобрать все сообщения фиксации для ^CL-(Add|Ref|Rem|Fix), чтобы добавить в список изменений.

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

Проще говоря: есть ли стандартная отраслевая стратегия или инструмент для извлечения полезных сообщений о совершении в списки изменений с легкостью?

Answer 1

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

После много экспериментов, что сработало для меня, тривиально: перед каждым выпуском один человек проходит журнал git со времени последнего выпуска и записывает все интересные вещи в файл изменений. Это действительно не больше работы, чем с другой стороны; большая часть работы решает, а не формулирует. И процесс принятия решения требует особого мышления, поэтому более эффективно, когда один человек делает это в большой партии, чем кучка разработчиков, выполняющих крошечные бит за раз. (Подумайте об этом так: вам не нужно постоянно менять «проверку сообщения клиента совершения транзакции» в задании и из кеша.)

Если вы действительно хотите пометить сообщения фиксации с помощью такой информации , вы должны хотя бы подумать об этом с git notes вместо сообщения raw commit. Затем, если кто-то его закроет, помечая фиксацию неправильно как ошибка/feature/etc, вы можете исправить ее, обновив аннотацию.

Answer 2

Я не знаю ни одного такого стандартного инструмента, но так как вы не получили ответ на какое-то время, вот некоторые идеи:

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

Что-то вроде CL: или Log: префикс для легкого извлечения, вероятно, хорошая идея. Что касается Add/Ref/Rem/Fix: (Я полагаю, что Ref и Rem стоят за «Refactor» и «Remove», верно?) Когда вы пишете журнал изменений, я предпочитаю придерживаться записей свободной формы. Например, я не уверен, что рефакторинг принадлежит списку изменений, а функции, которые достаточно высоки, чтобы гарантировать записи изменений, обычно не удаляются напрямую - они скорее заменяются на другую форму.

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

Я бы сказал, поставить высокоуровневое описание (CL: -tagged) в одном абзаце сообщения фиксации и нижнем техническом описании уровня в другом пункте.

или несколько сообщений, касающихся той же проблемы с изменением.

Мы говорим о чем-то подобном, не так ли?

1. (2011-01-03) CL: Измененный whizbar умолчанию 200.
2. (2011-01-11) CL: Измененный whizbar по умолчанию до 150, или 250, если foosnub верно.

И здесь я думаю, что «автоматическое изменение» вещь становится сложной. Если вы не захотите переустанавливать и редактировать сообщения фиксации после факта (например, удаление «CL:» из commit (1) выше), я бы предположил, что единственный практический способ сделать это - каждый раз, когда вы делаете выпуск , чтобы извлечь все помеченные абзацы из журнала git с момента последней версии и вручную отредактировать полученный список, объединив вещи, подобные (1) и (2) выше, и поверните, скажем, «Исправлено # 145», «Исправлено # 153 "," Исправлено # 164 "в одну строку" Исправлено # 145, # 153 и # 164 ".

Надеюсь, что я смог обеспечить некоторое вдохновение. Дайте нам знать, что вы делаете!

Answer 3

Посмотрите на vclog.