1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-AntV-F2

Клонировать/Скачать
CONTRIBUTING.zh-CN.md 8.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 29.06.2025 08:04 2a01c24

Правила внесения кода

Если у вас есть вопросы, пожалуйста, создайте issue, или напрямую отправьте PR!

Создание issue

  • Убедитесь, что вы определили тип issue.
  • Избегайте создания повторяющихся issue, прежде чем создать issue, выполните поиск существующих.
  • В метках (см. Классификация меток), заголовке или содержании укажите конкретную цель.

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

Внесение кода

Отправка Pull Request

Если у вас есть права доступа к репозиторию и вы хотите внести изменения в код, вы можете создать ветку, внести изменения и отправить Pull Request. Разработчики команды AntV проверят и объединят изменения с основной веткой.

# Сначала создайте ветку для разработки, название ветки должно быть осмысленным, избегайте использования update, tmp и т.п.
$ git checkout -b branch-name

# Установите зависимости и инициализируйте проект
$ npm i
$ npm run bootstrap

# После завершения разработки запустите тесты, если необходимо, добавьте или измените тестовые случаи
$ npm test

# После успешного прохождения тестов, добавьте изменения, сообщение см. ниже
$ git add . # git add -u для удаления файлов
$ git commit -m "fix(role): role.use должен быть xxx"
$ git push origin branch-name

После отправки вы сможете создать Pull Request на f2. Для удобства просмотра истории в будущем, убедитесь, что при отправке MR вы указали следующую информацию:

  1. Точка запроса (обычно связана с issue или комментарием)
  2. Причина обновления (отличается от issue, можно кратко описать, почему требуется обработка)
  3. Тестовые точки фреймворка (можно связать с тестовым файлом, подробное описание не требуется, достаточно ключевых моментов)
  4. Ключевые моменты (относительно пользователя, может отсутствовать, обычно это неполное обновление, требующее дополнительных уведомлений)

Стиль кода

Ваш стиль кода должен соответствовать eslint, вы можете выполнить локальную проверку с помощью $ npm run lint.

Нормы коммитов

Согласно нормам Angular отправляйте коммиты, что позволит более чётко видеть историю и автоматически генерировать changelog.

<type>(<scope>): <subject>
<Пустая строка>
<body>
<Пустая строка>
<footer>

(1) type

Тип коммита, включает следующие варианты:

  • feat: новая функция
  • fix: исправление проблемы
  • docs: изменение документации
  • style: изменение формата кода, не влияющее на логику
  • refactor: рефакторинг кода, теоретически не влияющий на существующие функции
  • perf: повышение производительности
  • test: добавление/изменение тестовых случаев
  • chore: изменения в инструментах (включая, но не ограничиваясь, документацией, генерацией кода и т.д.)
  • deps: обновление зависимостей

(2) область измененияОбласть изменения файла

(3) тема

Опишите одной строкой, что было сделано в этом коммите

(4) описание

Дополнительно расширяет тему, добавляя причины, цели и другие факторы, если это необходимо.

(5) подвал

  • Если есть несовместимые изменения (Breaking Change), их следует подробно описать здесь
  • Связывает с соответствующими issue, например Закрыто #1, Закрыто #2, #3

Пример

fix($compile): [BREAKING_CHANGE] несколько юнит-тестов для IE9

Старые версии IE сериализуют HTML с заглавными буквами, но IE9 нет...
Было бы лучше ожидать регистронезависимость, к сожалению, Jasmine не позволяет использовать регулярные выражения для ожиданий исключений.

Изменение документировано в antvis/f2#12

Закрыто #392

BREAKING CHANGE:

  Брейк в api foo.bar, следует использовать foo.baz вместо него

Просмотреть конкретные инструкции

Управление выпусками

f2 использует semver семантические версии для выпусков.

Ветка master является текущей стабильной версией.

  • Ветки разработки создаются непосредственно из master.
  • Все устаревшие API должны иметь предупреждение о deprecation в текущей стабильной версии и обеспечивать обратную совместимость до выпуска новой версии.

Политика выпуска

Каждый основной выпуск имеет менеджера выпуска (PM), которому нужно выполнить следующие действия#### Подготовительные работы:

  • Создать майлстоун, подтвердить соответствие требований майлстоуну, назначить и обновлять задачи.

Перед выпуском:

  • Подтвердить, что все задачи текущего майлстоуна закрыты или отложены, завершить тестирование производительности.
  • Инициировать новый Proposal MR для выпуска, составить историю в соответствии с node CHANGELOG, исправить содержание документации, связанное с версией, коммиты могут быть автоматически сгенерированы.
    $ npm run commits
  • Назначить менеджера следующего основного выпуска.

При выпуске:

  • Сохранить старую стабильную версию (master) в ветке с названием текущего основного выпуска (например 1.x) и установить тег {v}.x (где v — текущая версия, например 1.x).
  • Выпустить новую стабильную версию на npm и уведомить верхние уровни фреймворков об обновлении.
  • Перед выполнением команды npm publish, рекомендуется ознакомиться с этой статьёй.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/mirrors-AntV-F2.git
git@api.gitlife.ru:oschina-mirror/mirrors-AntV-F2.git
oschina-mirror
mirrors-AntV-F2
mirrors-AntV-F2
master