Стратегия извлечения сообщений наиболее полезных коммитов в журнал изменений

Question

Потребность в этом вопросе

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

Взгляните на vclog .

Answer 3

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

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

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

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

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

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

Мы говорим о чем-то вроде этого, верно?

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

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

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