Руководство по вкладу

Если у вас есть какие-либо замечания или предложения, пожалуйста, сообщите о вашей проблеме или сделайте любые изменения по своему желанию и отправьте PR.

Объявление новых проблем

• Укажите тип проблемы.
• Перед тем как сообщить о проблеме, пожалуйста, проведите поиск по связанным проблемам. Убедитесь, что вы не собираетесь открыть дубликат проблемы.
• Ясно объясните цель в метках (см. Полезные метки), заголовке или содержании.

Члены группы AntV проверят цель проблемы, заменят более точными метками, определят связанную версию и назначат разработчиков для работы над ней.

Отправка кода

Руководство по созданию PR

Если вы разработчик репозитория AntV и готовы сделать вклад, смело создайте новую ветку, завершите свои изменения и отправьте PR. Группа AntV проверит ваш вклад и сложит его с основной веткой.

# Создайте новую ветку для разработки. Название ветки должно быть семантическим, избегайте слов типа 'обновление' или 'временная'. Мы рекомендуем использовать feature/xxx, если изменения направлены на реализацию нового функционала.
$ git checkout -b branch-name

# После завершения ваших изменений запустите тесты. Добавьте новые тестовые случаи или измените старые, если это необходимо.
$ npm test
```# Если ваши изменения прошли тесты, поздравляем! Пришло время отправить ваш вклад обратно. Обратите внимание, что сообщение о коммите должно быть записано в следующем формате.
```bash
$ git add .
# git add -u для удаления файлов
$ git commit -m "fix(роль): метод role.use должен быть xxx"
$ git push origin имя-ветки

Затем вы можете создать Pull Request на g2plot.

Никто не может гарантировать, сколько времени будет помниться конкретный PR. Чтобы легко восстановить информацию о предыдущих действиях, предоставьте следующие данные в вашем PR:

1. Нужность: Какую функцию вы хотите реализовать (обычно укажите, какая проблема связана).
2. Причина обновления: В отличие от проблемы, кратко опишите причину и логику вашего обновления.
3. Связанные тесты: Кратко опишите часть тестов, относящуюся к вашим изменениям.
4. Советы пользователям: Предупреждение для пользователей g2plot. Вы можете пропустить этот раздел, если PR не связан с обновлением API или потенциальными проблемами совместимости.### Стиль оформления кода

Eslint может помочь выявить проблемы с оформлением кода, которые могут существовать в вашем проекте. Ваш код должен проходить тестирование от Eslint. Выполните локальное тестирование командой $ npm run lint.

Формат сообщений коммитаВы можете использовать формат сообщений коммита Angular для записи сообщений коммита. Таким образом, мы сможем иметь более отслеживаемую историю и автоматически генерируемый список изменений.```xml

(): <Пустая строка>

(1) type

Должен быть одним из следующих:

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

(2) scope

Область может быть любой, указывающей место изменения коммита.

(3) subject

Используйте краткие слова для описания того, что было сделано в этом коммите.

(4) body

Не стесняйтесь добавлять больше информации в теле сообщения, если считаете, что тема недостаточно самодостаточна, например, цель или причина вашего коммита.

(5) footer

• Если коммит является разрывом совместимости, пожалуйста, укажите это явно в этой части.
• связанные задачи, такие как Закрыто #1, Закрыто #2, #3

Пример:

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

Старые версии IE сериализуют HTML в верхнем регистре, но IE9 этого не делает...
Было бы лучше ожидать регистронезависимость, однако Jasmine не позволяет использовать регулярные выражения для проверки выбросов.
```Документация изменений на antvis/g2plot#123

Закрыто #392

BREAKING CHANGE:

  Разрыв в API `foo.bar`, следует использовать `foo.baz` вместо него

Смотрите [эти файлы](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) для получения дополнительной информации.

## Версия

g2plot использует семантическое версионирование при выпуске новых версий на основе [semver].

### Стратегия ветвей

ветка `master` — это последняя стабильная версия.

- просто переключитесь на ветку `develop` из `master`
- Все новые функции будут добавлены в ветку `master` или `next`, а также все исправления ошибок, кроме проблем безопасности. Так мы можем мотивировать разработчиков обновляться до последней стабильной версии.

### Стратегия выпуска

При каждом выпуске стабильной версии будет назначен менеджер проекта (PM), который будет выполнять следующие обязанности в различных этапах выпуска.

#### Подготовка

- Установите майлстоун. Подтвердите, что запрос связан с майлстоуном.

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

- Подтвердите, что тест производительности пройден и все проблемы в текущем майлстоуне либо закрыты, либо могут быть отложены до последующих версий.
- Откройте новый [требование к выпуску MR](https://github.com/nodejs/node/pull/4181) и запишите историю как [node CHANGELOG](https://github.com/nodejs/node/blob/master/CHANGELOG.md). Не забудьте исправить содержание документации, связанное с выпускаемой версией. Коммиты можно сгенерировать автоматически.  ```bash
  $ npm run commits

• Назначьте PM для следующей стабильной версии.