Слияние кода завершено, страница обновится автоматически
Вы можете отправить любые ошибки, проблемы и запросы на новые возможности в этом репозитории.
У нас есть очень строгие правила относительно того, как должны быть оформлены сообщения коммитов в нашем Git. Это приводит к более читаемым сообщениям, которые легко просматривать при просмотре истории проекта.
Каждое сообщение коммита состоит из шапки, тела и подвала. Шапка имеет специальный формат, который включает тип, область применения и тему:
<type>(<scope>): <subject>
<Пустая строка>
<body>
<Пустая строка>
<footer>
Шапка с типом обязательна. Область применения шапки является необязательной. Этот репозиторий не имеет зарезервированных областей применения. Можно использовать пользовательскую область применения для ясности, если это требуется.
Любой строкой сообщения коммита не может быть длиннее 100 символов! Это позволяет сообщению быть легче воспринимаемым на GitHub, а также в различных инструментах Git.
Подвал должен содержать ссылку на закрытие задачи (закрытие ссылки на задачу), если таковая имеется.
Пример 1:
feat: добавление файлов композа для выпуска Fuji
fix(скрипт): исправление запуска скрипта для использования правильных портов
```Ранее сервисы устройств использовали неверные номера портов. Этот коммит исправляет номера портов, чтобы они соответствовали последним номерам портов.
Закрывает: #123, #245, #992
```markdown
### Откат
Если коммит отменяет предыдущий коммит, он должен начинаться со слова `revert: `, за которым следует шапка отмененного коммита. В теле должно быть указано: `Это отменяет коммит <hash>.`, где `<hash>` — это SHA предыдущего коммита.
### Тип
Должен быть одним из следующих:
- **feat**: Новый функционал для пользователя, но не новый функционал для скрипта сборки
- **fix**: Исправление ошибки для пользователя, но не исправление скрипта сборки
- **docs**: Изменения только в документации
- **style**: Форматирование, отсутствие точек с запятой и т.д.; изменения не затрагивают производственные данные
- **refactor**: Переработка производственного кода, например переименование переменной
- **chore**: Обновление задач Grunt и т.д.; изменения не затрагивают производственные данные
- **perf**: Изменение кода, которое повышает производительность
- **test**: Добавление недостающих тестов, переработка тестов; изменения не затрагивают производственные данные
- **build**: Изменения, которые влияют на систему CI/CD, систему сборки или внешние зависимости (например области применения: Jenkins, Makefile)
- **ci**: Изменения, предоставленные отделом DevOps для целей CI.
- **revert**: Отмена предыдущего коммита.
```Для этого репозитория нет заранее определённых областей применимости. Можно указать пользовательскую область для ясности.
### Тема
Тема должна содержать краткое описание изменения:
- используйте повелительное наклонение в настоящем времени: "измените", а не "изменено" или "изменяет"
- первая буква не должна быть прописной
- не ставьте точки в конце
### Описание
Как и в теме, используйте повелительное наклонение в настоящем времени: "измените", а не "изменено" или "изменяет". Описание должно включать мотивацию для изменения и контрастировать это с предыдущим поведением.
### Подвал
Подвал должен содержать информацию о **разрушительных изменениях** и также является местом для ссылки на задачи GitHub, которые этот коммит **закрывает**.
**Разрушительные изменения** должны начинаться со слов `BREAKING CHANGE:` с пробела или двух пустых строк. Оставшаяся часть сообщения коммита используется для этого.
## Журнал изменений
Изменения, затрагивающие функциональность EMQX, должны быть описаны отдельным файлом markdown в директории `changes`.
Шаблон имени файла: `changes/(ce|ee)/(feat|perf|fix)-<PR-id>.ru.md`, где:- `ce,ee`: Указывает, влияет ли данное изменение на версию для сообщества и предприятия (`ce`) или только на предприятие (`ee`). Для любого изменения требуется всего один файл, так как версия для предприятия автоматически включает все изменения из версии для сообщества. В случае сомнений можно обратиться к [документации](https://www.emqx.io/docs/ru/latest/). Функции для предприятия имеют соответствующий баннер "Совет", см., например, [здесь](https://www.emqx.io/docs/ru/v5.1/data-integration/data-bridge-influxdb.html).
- `feat|perf|fix`: Указывает, является ли изменение новой функциональностью (`feat`), улучшением производительности (`perf`) или исправлением ошибки (`fix`).
- `PR-id`: Id запроса на слияние GitHub. Поскольку id запроса на слияние не известен до его создания, обычно журнал изменений добавляется в отдельном коммите.
- `en`: Код языка ISO 639-1, указывающий язык журнала изменений. В данный момент мы принимаем записи только на английском языке.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )