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

OSCHINA-MIRROR/antv-g2plot-antv-g2plot

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.zh-CN.md 8.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 25.11.2024 23:57 fa31d76

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

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

Отправка issue

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

После этого ответственный за AntV подтвердит намерение issue, обновит соответствующие теги, свяжет с milestone и назначит разработчика.

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

Отправка Pull Request

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

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

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

# После успешного прохождения тестов отправьте код, сообщение см. ниже

$ git add . # git add -u удалить файл
$ git commit -m "fix(role): role.use должен xxx"
$ git push origin branch-name

После отправки вы можете создать Pull Request на g2plot.

Чтобы облегчить последующее отслеживание истории, при отправке MR убедитесь, что вы предоставили следующую информацию:

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

Стиль кода

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

Правила оформления коммитов

Следуйте формату сообщений о коммитах angular, чтобы история выглядела более чётко и автоматически генерировался changelog.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

(1) type

Тип фиксации включает следующие типы:

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

(2) scope

Диапазон изменений файла

(3) subject

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

(4) body

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

(5) footer

При наличии несовместимых изменений (Breaking Change) обязательно опишите их здесь — Свяжите с соответствующими issue, например Closes #1, Closes #2, #3

Пример:

fix($compile): [BREAKING_CHANGE] несколько модульных тестов для IE9

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

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

Закрывает #392

BREAKING CHANGE:

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

Для получения дополнительной информации см. документацию.

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

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

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

— Непосредственно разветвите ветвь разработки из master — Все устаревшие API должны быть отмечены как deprecated в текущей стабильной версии, и должна быть обеспечена совместимость до новой версии выпуска.

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

Каждый основной выпуск имеет менеджера по выпуску (PM), который отвечает за следующее:

Подготовка:

— Создание milestone, подтверждение связи с issues и назначение.

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

— Убедитесь, что все issues в текущем milestone закрыты или могут быть отложены, а также завершите тестирование производительности. — Создайте новый Release Proposal MR, напишите историю в соответствии с node CHANGELOG, исправьте связанные с версией документы, коммиты могут быть автоматически сгенерированы.

$ npm run commits

— Укажите следующего менеджера основного выпуска.

Во время выпуска:

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

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

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

1
https://api.gitlife.ru/oschina-mirror/antv-g2plot-antv-g2plot.git
git@api.gitlife.ru:oschina-mirror/antv-g2plot-antv-g2plot.git
oschina-mirror
antv-g2plot-antv-g2plot
antv-g2plot-antv-g2plot
master