Слияние кода завершено, страница обновится автоматически
Этот гайд содержит инструкции о том, когда и как следует создавать запись в истории изменений, а также информацию и историю о нашем процессе ведения истории изменений.
Каждая запись, или вход, в нашем файле CHANGELOG.md генерируется из одного файла данных в папке changelogs/unreleased/ (или соответствующей EE). Файл ожидается быть файлом YAML в следующем формате:
---
title: "Прохождение через изменения[логи]"
merge_request: 1972
author: Ozzy Osbourne
Значение merge_request является ссылкой на запрос слияния, который добавляет эту запись, а ключ author используется для предоставления атрибуции для участников сообщества. Оба значения являются необязательными.
Участники сообщества и члены основной команды поощряются добавлять свои имена в поле author. Члены команды GitLab не должны этого делать.
Хорошая запись в истории изменений должна быть описательной и краткой. Она должна объяснять изменение для читателя, который имеет нулевой контекст об этом изменении. Если вы испытываете трудности с тем, чтобы сделать запись одновременно краткой и описательной, лучше склоняться к описательности.
Первый пример не предоставляет контекста о том, где было внесено изменение, почему или как это изменение полезно для пользователя.
Вновь, первый пример слишком расплывчат и не предоставляет контекста.
Первый пример слишком сосредоточен на деталях реализации. Пользователь не интересуется тем, что мы изменили в CSS и HTML, он интересуется конечным результатом этих изменений.- Плохо: Удаляет nil из массива объектов коммитов, возвращаемых из find_commits_by_message_with_elastic.
Используйте свое лучшее суждение и попытайтесь поставить себя на место человека, читающего сгенерированный changelog. Добавляет ли этот ввод ценность? Предоставляет ли он контекст о где и почему была сделана эта правка?
Доступен скрипт bin/changelog для автоматической генерации файла ввода changelog.
Его самое простое использование — предоставление значения для title:
$ bin/changelog 'Привет DZ, я добавил функцию в GitLab!'
Имя файла ввода основано на имени текущей ветки Git. Если вы запустите команду выше на ветке feature/hey-dz, она сгенерирует файл changelogs/unreleased/feature-hey-dz.yml.
Команда выведет путь к сгенерированному файлу и его содержимое:
create changelogs/unreleased/my-feature.yml
---
title: Привет DZ, я добавил функцию в GitLab!
merge_request:
author:
Если вы работаете в репозитории GitLab EE, ввод будет добавлен в changelogs/unreleased-ee/ вместо этого.#### Аргументы| Аргумент | Сокращение | Цель |
| ----------------- | --------- | --------------------------------------------- |
| [--amend] | | Изменить предыдущий коммит |
| [--force] | -f | Перезаписать существующий ввод |
| [--merge-request] | -m | Установить идентификатор запроса слияния |
| [--dry-run] | -n | Не записывать ничего, только вывод |
| [--git-username] | -u | Использовать конфигурацию Git user.name как автора |
| [--help] | -h | Вывести сообщение помощи |[--amend]: #-amend
[--force]: #-force-or-f
[--merge-request]: #-merge-request-or-m
[--dry-run]: #-dry-run-or-n
[--git-username]: #-git-username-or-u
[--help]: #-help##### --amend
Вы можете передать аргумент --amend для автоматической стадии сгенерированного файла и внесения изменений в предыдущий коммит.
Если вы используете --amend и не предоставляете заголовок, он автоматически будет использовать "тему" предыдущего коммита, что является первой строкой сообщения о коммите:
$ git show --oneline
ab88683 Добавлено отличное новое функциональное поле в GitLab
$ bin/changelog --amend
create changelogs/unreleased/feature-hey-dz.yml
---
title: Добавлено отличное новое функциональное поле в GitLab
merge_request:
author:
--force или -f
Используйте аргумент --force или -f для перезаписи существующего внесенного изменения, если оно уже существует.
$ bin/changelog 'Привет DZ, я добавил функциональное поле в GitLab!'
ошибка: changelogs/unreleased/feature-hey-dz.yml уже существует! Используйте `--force` для перезаписи.
$ bin/changelog 'Привет DZ, я добавил функциональное поле в GitLab!' --force
create changelogs/unreleased/feature-hey-dz.yml
---
title: Привет DZ, я добавил функциональное поле в GitLab!
merge_request: 1983
author:
--merge-request или -m
Используйте аргумент --merge-request или -m для предоставления значения merge_request:
$ bin/changelog 'Привет DZ, я добавил функциональное поле в GitLab!' -m 1983
create changelogs/unreleased/feature-hey-dz.yml
---
title: Привет DZ, я добавил функциональное поле в GitLab!
merge_request: 1983
author:
--dry-run или -n
--dry-run или -n для предотвращения фактической записи или коммита:```text
$ bin/changelog --amend --dry-run
create changelogs/unreleased/feature-hey-dz.ymltitle: Добавлено отличное новое функциональное поле в GitLab merge_request: author:
$ ls changelogs/unreleased/
##### `--git-username` или `-u`
Используйте аргумент **`--git-username`** или **`-u`** для автоматического заполнения значения `author` с вашим настроенным значением Git `user.name`:
```text
$ git config user.name
Jane Doe
$ bin/changelog -u 'Привет DZ, я добавил функциональное поле в GitLab!'
create changelogs/unreleased/feature-hey-dz.yml
---
title: Привет DZ, я добавил функциональное поле в GitLab!
merge_request:
author: Jane Doe
Наш файл CHANGELOG ранее обновлялся вручную каждым вкладчиком, который считал, что его изменения заслуживают внесения в список. Когда два запроса на слияние добавляли свои собственные записи в одно и то же место в списке, это создавало конфликт слияния сразу после того, как другой запрос на слияние был включен. Когда у нас было десятки запросов на слияние, боровшихся за одно и то же место в списке изменений, это быстро стало основным источником конфликтов слияния и задержек в разработке. Это привело нас к [скучному решению] "добавьте вашу запись в случайное место в списке". На самом деле это работало довольно хорошо по мере продвижения каждого месячного цикла выпуска, но в начале нового цикла, когда добавлялся новый раздел версий и было меньше мест для "случайного" добавления записи, конфликты снова становились проблемой, пока количество записей не становилось достаточным.
```Кроме всего прочего, это создало совершенно другую проблему для [менеджеров выпуска], когда они выбирали отдельные коммиты для добавления в стабильную ветку для выпуска патча. Если коммит включал запись в CHANGELOG, он включал бы полный `CHANGELOG` для последней версии в `master`, поэтому менеджеру выпуска приходилось вручную удалять более поздние записи. Они часто должны были это делать несколько раз на каждый патч-выпуск. Это усугублялось, когда нам приходилось выпускать несколько патчей одновременно из-за проблемы безопасности.
Мы нуждались в автоматизации всего этого ручного труда. Поэтому мы начали мозговой штурм. После многочисленных обсуждений мы остановились на текущем решении одного файла на запись, а затем компилировали записи в общий файл CHANGELOG.md во время [процесса выпуска].
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )