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

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

если вы называете свои ветви красиво, так что слияние с мастером отображается как что-то вроде "Merged branch feature-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.

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

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

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

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

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

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

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

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

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

соглашение о фиксации сообщений

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

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

• по намерению (например: новый, исправить, изменить ...)
• по объекту (например: doc, упаковка, код ...)
• аудитории (например, разработчика, тестера, пользователей ...)

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

• как" незначительные " коммиты, которые не должны выводиться в ваш журнал изменений (косметические изменения, небольшая опечатка в комментариях...)
• как "рефактор", если у вас действительно нет каких-либо существенных изменений функций. Таким образом, это не должно также быть частью списка изменений, отображаемого конечному пользователю, например, но может даже если у вас есть чейнджлог разработчика.
• вы также можете пометить "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 до changelog инструменты там же.

еще до момента изменений. Скажите мне, если вам это нравится.

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

The 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-generator

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

Это CHANGELOG.md был сгенерирован этим скриптом.

пример:

список изменений

1.2.5 (2015-01-15)

полный Список изменений

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

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

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

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

Объединенные запросы на вытягивание:

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

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

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

• храниться в файл, например CHANGELOG.md.
• быть отправлены в MediaWiki
• или просто быть напечатаны на STDOUT

Я тоже:

• A плагин Gradle в
• A Maven плагин
• A Дженкинс плагин
• A Bitbucket Server plugin
• 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 и т. д.

на основе 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 до v1.0.1.

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

---

на GNU style changelog, я приготовил функция

gnuc() {
  {
    printf "$(date "+%Y-%m-%d")  John Doe  <[email protected]>\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  <[email protected]>

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

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

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

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

• https://github.com/tromey/git-gnu-changelog by Tromey, a GDB maintainer
• ССАГПЗ contrib / mklog
• https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/1fc7fe038bffbb2b48d0a7a300625639f01aefa1/generate-changelog.py

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

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

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

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