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

$ git log --format=%B -n 1 <sha-1> > filename.txt

Это дает вам комментарий для указанной фиксации SHA-1 и перенаправляет его в файл. Пока у вас есть значение SHA-1, вы сможете обернуть его на свой любимый язык и настроить для динамической вставки вывода там, где это необходимо.

Идентификация коммита

Универсальным идентификатором каждого коммита является его SHA1 — 40-значное шестнадцатеричное число, подобное этому:

3e0b5fb09d70d0457d7e5ae7892504f6e1b45f33

Этот коммит взят из репозитория конструктора документации Sphinx. В комментарии говорится:

Merge pull request #4556 from tk0miya/4543_autodoc_test_fails_with_py353

Fix #4543: test for autodoc fails with python 3.5.3

Разумный способ сделать постоянную ссылку на коммит — сохранить его SHA1 и использовать его для доступа к коммиту через различные интерфейсы — см. примеры ниже.

Получение сведений о коммите

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

Командная строка и локальный репозиторий

Первый вариант — когда код имеет доступ файловой системы к репозиторию.

$ git show -s --format=%B 3e0b5fb09d70d0457d7e5ae7892504f6e1b45f33

Merge pull request #4556 from tk0miya/4543_autodoc_test_fails_with_py353

Fix #4543: test for autodoc fails with python 3.5.3

Существуют различные --formatварианты получения необходимых сведений о коммите.

API и удаленный репозиторий

Вы также можете использовать SHA1 для получения сведений о коммите из удаленного репозитория. Скажем, у вас есть самостоятельная установка GitLab, и вы хотели бы получать сообщение коммита через GitLab API . Вот как может выглядеть запрос GET:

curl --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" \
"https://gitlab.example.com/api/v4/projects/5/sphinx/commits/3e0b5fb09d70d0457d7e5ae7892504f6e1b45f33"

Ответ представляет собой JSON с большим количеством деталей коммита.

Выбор коммитов

Если вы хотите автоматически выбирать значимые коммиты, вам нужно какое-то правило или соглашение, чтобы ваша команда отмечала такие коммиты.

Например, многие команды работают с методологиями «поток git» или «поток GitHub/GitLab», в которых работа выполняется в функциональных ветках, а затем объединяется в стабильную ветку. Каждое слияние приводит к фиксации слияния. Если члены вашей команды пишут осмысленные сообщения в коммитах слияния, это хороший источник для журнала изменений.

Чтобы получить сообщения фиксации слияния, используйте git log --merges. В этом примере мы получаем хэш (SHA1, %H), дату создания ( %ad) и сообщение фиксации ( %B), разделенные символами новой строки ( %n):

$ git log --format='%H%n%at%n%B' --merges   

Вы можете захотеть упаковать вывод в какой-нибудь удобный формат, например JSON:

$ git log  --merges --format='{%n  "hash": "%H",%n  "timestamp": %at,%n  "subject": "%s"%n}'
{
  "hash":3e0b5fb09d70d0457d7e5ae7892504f6e1b45f33,
  "timestamp": 1517848081,
  "subject": "Merge pull request #4556 from tk0miya/4543_autodoc_test_fails_with_py353"
}

...

Здесь применяется тот же список --formatопций .

Несколько дней назад я видел сообщение именно об этой идее на слабом канале WtD — я хочу сказать, что этот подход назывался typson + docson, и он напрямую извлекал комментарии в систему документации с места в карьер — обсуждение на базе пользователей, похоже, указывало на то, что это предназначено как внутренняя система документов, ей потребуются небольшие настройки, но этого будет достаточно.

Нашел это в своей истории - надеюсь, это поможет.

ссылка на демонстрационную страницу: http://lbovet.github.io/typson-demo/

ссылка на страницу docson github: https://github.com/lbovet/docson

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