Вклад в LinDB
Шаги для внесения вклада
- Если вы хотите поработать над задачей, пожалуйста, сначала заявите о своём желании, оставив комментарий к задаче GitHub, над которой вы хотите работать. Это позволит избежать дублирования усилий со стороны участников, работающих над одной и той же задачей.
- Создайте форк проекта (не отправляйте ветки непосредственно в основной репозиторий).
- Создайте ветку для своих изменений.
- Внесите изменения и добавьте тесты (модульные тесты/интеграционные тесты).
- Зафиксируйте изменения, следуя рекомендациям по оформлению сообщений о фиксации.
- Отправьте ветку с изменениями в свой форк.
- Откройте запрос на включение в проект LinDB.
Тестирование
По возможности следует добавлять тестовые случаи для охвата новой функциональности или исправленной ошибки. Тестовые случаи должны быть небольшими, целенаправленными и быстрыми в выполнении.
Запросы на включение
Следующие рекомендации помогут обеспечить лёгкость проверки и понимания запросов на включение (PR):
-
Один PR решает одну проблему, объединение нескольких проблем в одном PR затрудняет проверку и слияние.
-
Одна фиксация на PR, финальное слияние должно иметь одну фиксацию с хорошим сообщением о фиксации. Обратите внимание, мы можем сквошить и объединить через GitHub, поэтому во время работы над изменением можно делать много фиксаций, а затем сквошить их, когда работа будет завершена. Исключением являются обновления зависимостей, где единственным изменением является версия зависимости. Обычно мы делаем это как пакет с отдельными фиксациями для каждой версии и объединяем без сквоша. В этом случае отдельные фиксации могут быть полезны для разрешения проблемы, начиная с изменения зависимости.
-
Указывайте связанные или исправленные проблемы, это помогает нам получить больше контекста для изменений.
-
Частичная работа приветствуется, отправьте её с заголовком, включающим
[WIP] (работа в процессе), чтобы указать, что она ещё не готова.
-
Держите нас в курсе, мы постараемся рассмотреть и объединить входящие PR. Мы можем закрыть PR после 30 дней бездействия. Это охватывает такие случаи, как: неудачные тесты, неразрешённые конфликты с основной веткой или нерешённые комментарии рецензента.
Метки задач
Для [задач][issue] мы используем следующие метки для быстрой категоризации задач:
| Метка |
Описание |
bug |
Подтверждённые ошибки или сообщения, которые, скорее всего, являются ошибками. |
enhancement |
Запросы на функции. |
discussion |
Просьбы о комментарии для определения направления. |
help wanted |
Помощь сообщества была бы признательна. Хорошие первые задачи. |
question |
Вопросы, выходящие за рамки отчётов об ошибках или запросов функций (например, как сделать X). |
Рекомендации по оформлению сообщений о фиксации
Сообщения о фиксации должны соответствовать следующим рекомендациям:
Формат
- тип: необходимо (
:#issue номер задачи необязателен)
- область: необязательно
- тема: необходимо
[тип:#issue][область]: тема
Тип
- feat: новая функция
- fix: исправленная ошибка
- docs: коммиты документации
- style: изменение стиля кода (изменение не влияет на логику кода)
- refactor: не добавляются ни новые функции, ни исправления ошибок
- test: изменения модульного теста
- chore: изменения процесса CI и инструментов CI
Область
Область используется для описания области влияния фиксации, такой как tsdb:index, broker:routes, storage и т. д.
Тема
Тема — это краткое описание сообщения о фиксации, не более 50 символов.
- используйте простое настоящее время глаголов, таких как
change, add, fix;
- первая буква строчная;
- не заканчивайте точкой (.);
Пример
- [feat]: добавить начальный коммит
- [chore:#1]: добавить Travis CI
- [test:#2]: добавить модульный тест для tsdb
- [fix:#3][model:point]: изменить тип timestamp с int64 на uint64
- [feat:#4][tsdb]: реализация memdb
- [docs:#7]: добавить руководство по формату сообщений о фиксации
Опубликовать ( 0 )