вы можете использовать некоторый вкус журнала git, чтобы помочь вам:

git log --pretty=%s                 # only print the subject

если вы называете свои ветви красиво, так что слияние с мастером отображается как что-то вроде "Объединенная функция ветви-foobar", вы можете сократить вещи, только показывая это сообщение, а не все маленькие коммиты, которые вы объединили, которые вместе образуют функцию:

git log --pretty=%s --first-parent  # only follow first parent of merges

возможно, вы сможете дополнить это собственным скриптом, который может делать такие вещи, как удаление битов " Объединенной ветви, нормализовать форматирование и т. д. В какой-то момент Вы должны написать его сами, хотя, конечно.

затем вы можете создать новый раздел для журнала изменений один раз за версию:

git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y

и зафиксируйте это в вашей версии Release commit.

если ваша проблема в том, что эти темы фиксации не похожи на то, что вы хотите поместить в журнал изменений, у вас в значительной степени есть два варианта: продолжайте делать все вручную (и старайтесь идти в ногу с ним более регулярно, а не воспроизведение догоняющего во время выпуска), или исправить свой стиль сообщения фиксации. Одним из вариантов, если субъекты не собираются делать это за вас, было бы разместить строки типа "изменить: добавлена функция foobar" в телах ваших сообщений фиксации, чтобы позже вы могли сделать что-то вроде git log --pretty=%B | grep ^change: чтобы захватить только те супер-важные части сообщения.

Я не совсем уверен, насколько больше, чем этот git может действительно помочь вам создать свои списки изменений. Возможно, я неправильно понял, что ты имеешь в виду. "управлять"?

отказ от ответственности: я автор книги gitchangelog о котором я буду говорить в следующем.

TL; DR: вы, возможно, захотите, чтобы проверить собственный журнал изменений гитчангелога или выход ascii это породило предыдущий.

если вы хотите создать журнал изменений из своей истории git, вам, вероятно, придется рассмотреть:

• the формат. (Чистый пользовательский ASCII, тип журнала изменений Debian, Markdow, ReST...)
• некоторые совершить фильтрации (вы, вероятно, не хотите видеть все опечатки или косметические изменения, попадающие в ваш журнал изменений)
• некоторые совершить текст пререкания до включения в changelog. (Обеспечение нормализации сообщений как имеющих верхний регистр первой буквы или конечную точку, но это может быть удаление некоторой специальной разметки в резюме)
• ваш git история совместима ?. Слияние, пометка, Не всегда так легко поддерживается большинством инструментов. Это зависит от того, как вы управляете своей историей.

Optionaly вам может понадобиться некоторая категоризация (новые вещи, изменения, исправления)...

имея все это в виду, я создал и использовать gitchangelog. Он предназначен для использования git commit message convention для достижения всех предыдущих целей.

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

соглашение о передаче сообщений

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

возможно, вы захотите разделить свои коммиты на большие разделы:

• по намерению (например: new, fix, change ...)
• по объекту (например: doc, упаковка, код ...)
• по аудитории (например: dev, tester, users ...)

кроме того, вы можете пометить некоторые коммиты:

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

попробуйте написать сообщение фиксации, ориентируясь на пользователей (функциональность) так часто, как вы можете.

пример

это стандартная git log --oneline чтобы показать, как эта информация может храниться::

* 5a39f73 fix: encoding issues with non-ascii chars.
* a60d77a new: pkg: added ``.travis.yml`` for automated tests. 
* 57129ba new: much greater performance on big repository by issuing only one shell command for all the commits. (fixes #7)
* 6b4b267 chg: dev: refactored out the formatting characters from GIT.
* 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor 
* 6b891bc new: add utf-8 encoding declaration !minor 

Итак, если вы заметили, формат, который я выбрал есть:

{new|chg|fix}: [{dev|pkg}:] COMMIT_MESSAGE [!{minor|refactor} ... ]

чтобы увидеть фактический результат вывода, вы можете посмотреть в конце страницы PyPI gitchangelog

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

как создать изысканный журнал изменений из этого

тогда довольно легко сделать полный список изменений. Вы могли бы сделать свой собственный сценарий довольно быстро, или использовать gitchangelog.

gitchangelog создаст полный список изменений (с поддержкой секционирования как New, Fix...), и разумно настраивается для ваших собственных соглашений о совершении. Он поддерживает любой тип вывода благодаря шаблону через Mustache, Mako templating, и имеет устаревший движок по умолчанию, написанный на сыром python ; все текущие 3 движка имеют примеры того, как их использовать, и могут выводить журнал изменений как тот, который отображается на странице PyPI gitchangelog.

я уверен, что вы знаете, что есть много других git log to changelog инструменты там же.

более к пункту CHANGELOG. Скажите мне, нравится ли вам это.

git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B

на gitlog-to-changelog скрипт пригодится для генерации GNU-стиля ChangeLog.

как показал gitlog-to-changelog --help, вы можете выбрать коммиты, используемые для создания ChangeLog файл, используя либо опцию --since:

gitlog-to-changelog --since=2008-01-01 > ChangeLog

или путем передачи дополнительных аргументов после --, который будет передан git-log (называется внутри gitlog-to-changelog):

gitlog-to-changelog -- -n 5 foo > last-5-commits-to-branch-foo

например, я использую следующее правило на верхнем уровне Makefile.am один из моих проекты:

.PHONY: update-ChangeLog
update-ChangeLog:
    if test -d $(srcdir)/.git; then                         \
       $(srcdir)/build-aux/gitlog-to-changelog              \
          --format='%s%n%n%b%n' --no-cluster                \
          --strip-tab --strip-cherry-pick                   \
          -- $$(cat $(srcdir)/.last-cl-gen)..               \
        >ChangeLog.tmp                                      \
      && git rev-list -n 1 HEAD >.last-cl-gen.tmp           \
      && (echo; cat $(srcdir)/ChangeLog) >>ChangeLog.tmp    \
      && mv -f ChangeLog.tmp $(srcdir)/ChangeLog            \
      && mv -f .last-cl-gen.tmp $(srcdir)/.last-cl-gen      \
      && rm -f ChangeLog.tmp;                               \
    fi

EXTRA_DIST += .last-cl-gen

это правило используется во время релиза обновления ChangeLog С последними еще не записанными сообщениями фиксации. Файл .last-cl-gen содержит идентификатор SHA1 последней фиксации, записанной в ChangeLog и хранится в репозитории Git. ChangeLog также записывается в репозиторий, чтобы его можно было редактировать (например, для исправления опечаток) без изменения сообщений фиксации.

поскольку Создание тега для каждой версии является лучшей практикой, вы можете захотеть разделить журнал изменений на версию. В этом случае, эта команда может помочь вам:

git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

на GitHub проекты это может быть полезно: GitHub-changelog-генератор

Он генерирует журнал изменений из тегов закрытых проблем и Объединенных pull-запросов.

этот чейнджлог.МД был создан этот скрипт.

пример:

изменений

1.2.5 (2015-01-15)

полный Changelog

реализованные улучшения:

• используйте milestone, чтобы указать, в какой версии была исправлена ошибка #22

исправлены ошибки:

• ошибка при попытке создать журнал для репо без тегов #32

слился запросы:

• класс PrettyPrint включен использование нижнего регистра 'pp'#43 (schwing)

• поддержка enterprise github через параметры командной строки #42 (glenlovett)

Я также сделал библиотеку для этого. Он полностью настраивается с помощью шаблона усов. Что может:

• быть сохранены в файл, как изменений.МД.
• быть отправлено в MediaWiki
• или просто быть напечатаны в STDOUT

Я тоже:

• A плагин Gradle в
• A Maven плагин
• A Дженкинс плагин
• A модуль сервера Bitbucket
• A командная строка

подробнее о Github:https://github.com/tomasbjerre/git-changelog-lib

git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort

это то, что я люблю использовать. Он получает все коммиты с последнего тега. cut избавляется от хэша фиксации. Если вы используете номера билетов в начале сообщений фиксации, они группируются с sort. Сортировка также помогает, если вы префикс определенных коммитов с fix, typo, etc.

на основе bithavoc на last tag до HEAD. Но я надеюсь перечислить журналы между 2 тегами.

// 2 or 3 dots between `YOUR_LAST_VERSION_TAG` and `HEAD`
git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

список журналов между 2 тегами.

// 2 or 3 dots between 2 tags
git log FROM_TAG...TO_TAG

например, он будет перечислять журналы из v1.0.0 to v1.0.1.

git log v1.0.0...v1.0.1 --oneline --decorate

на журнал изменений в стиле GNU, я приготовил функция

gnuc() {
  {
    printf "$(date "+%Y-%m-%d")  John Doe  <john.doe@gmail.com>\n\n"
    git diff-tree --no-commit-id --name-only -r HEAD | sed 's/^/\t* /'
  } | tee /dev/tty | xsel -b
}

С этого:

• я периодически фиксирую свои изменения в резервную копию и перебазирую их перед окончательным редактированием в журнал изменений
• запустите: gnuc

и теперь мой буфер обмена содержит что-то вроде:

2015-07-24  John Doe  <john.doe@gmail.com>

        * gdb/python/py-linetable.c (): .
        * gdb/python/py-symtab.c (): .

затем я использую буфер обмена в качестве отправной точки для обновления изменений.

это не идеально (например, файлы должны быть относительно их пути журнала изменений, поэтому python/py-symtab.c без gdb/ так как я буду редактировать gdb/ChangeLog), но это хорошая отправная точка.

более продвинутый скрипт:

• https://github.com/tromey/git-gnu-changelog от Tromey, сопровождающий GDB
• GCC contrib / mklog
• https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/1fc7fe038bffbb2b48d0a7a300625639f01aefa1/generate-changelog.py

Я должен согласиться с Тромеем: дублирование данных фиксации git в журнале изменений бесполезно.

если вы собираетесь сделать журнал изменений, сделайте его хорошим резюме того, что происходит, возможно, как указано в http://keepachangelog.com/

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

>git log --graph --all --date=relative --pretty=format:"%x09 %ad %d %s (%aN)"