Хорошие способы управления списком изменений с помощью git?

Я использую Git какое-то время, и недавно я начал использовать его, чтобы пометить мои выпуски, чтобы я мог легче отслеживать изменения и видеть, в какой версии работает каждый из наших клиентов ( к сожалению, код в настоящее время требует, чтобы у каждого клиента была своя копия сайта PHP, я меняю это, но это медленно).

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

Я попробовал googling "git changelog" и "git управлять списком изменений", но я не нашел ничего, что действительно говорило о рабочем процессе изменений кода и о том, как это совпадает с журналом изменений. Мы в настоящее время следуем рабочий процесс разработки Рейна Хенрикса, и мне бы понравилось то, что с ним связано.

Есть ли стандартный подход, который мне не хватает, или это область, где каждый делает свою собственную вещь?

Большое спасибо за ваши комментарии/ответы!

ОТВЕТЫ

Ответ 1

Это было около 3-4 лет назад, но для будущих искателей теперь можно создавать великолепные журналы с помощью:

git log --oneline --decorate

Или, если вы хотите, чтобы он был еще красивее (с цветом для терминала):

git log --oneline --decorate --color

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

Ответ 2

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

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

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

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

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

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

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

и зафиксировать, что в вашей версии релиза совершить.

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

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

Ответ 3

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я автор gitchangelog, о котором я буду говорить в следующий.

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

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

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

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

Учитывая все это, я создал и использовал gitchangelog. Это означало использовать соглашение git фиксации сообщения для достижения всех предыдущих целей.

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

фиксация сообщения

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

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

  • по замыслу (например: new, fix, change...)
  • по объекту (например: документ, упаковка, код...)
  • аудитории (например: dev, тестер, пользователи...)

Кроме того, вы можете захотеть отметить некоторые коммиты:

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

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

Затем довольно легко сделать полный журнал изменений. Вы можете сделать свой собственный script достаточно быстро или использовать gitchangelog.

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

Для проектов GitHub это может быть полезно: github-changelog-generator

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

Этот CHANGELOG.md был создан этим script.

Пример:

Changelog

1.2.5 (2015-01-15)

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

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

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

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

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

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

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

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

Ответ 8

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

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

Я также сделал:

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

введите описание изображения здесь

Ответ 9

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

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

Ответ 10

На основе 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 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

Ответ 11

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

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
}

При этом:

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

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

2015-07-24  John Doe  <[email protected]>

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

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

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

Более сложные скрипты:

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

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

Ответ 12

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

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