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

OSCHINA-MIRROR/serverless-devs-Serverless-Devs

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 18 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 24.05.2025 16:44 c46f8bb

Внесение вклада в Serverless Devs

Если вас интересует внесение вклада в Serverless Devs, мы с радостью приветствуем ваше участие. В этом разделе вы найдете руководство по внесению вклада.

Темы

Сообщение о проблемах безопасности

Проблемы безопасности всегда рассматриваются серьезно. В соответствии с нашими обычными принципами, мы не рекомендуем никому распространять информацию о проблемах безопасности. Если вы обнаружили проблему безопасности в Serverless Devs, пожалуйста, не обсуждайте её публично и не открывайте публичный запрос. Вместо этого мы рекомендуем отправить нам приватное письмо на адрес service@serverlessfans.com для сообщения о проблеме.## Сообщение о общих проблемах

Откровенно говоря, мы считаем каждого пользователя Serverless Devs ценным вкладчиком. После использования Serverless Devs у вас могут быть отзывы о проекте. Тогда вы можете открыть запрос через НОВЫЙ ЗАПРОС.

Так как проект Serverless Devs развивается распределённо, мы ценим ПОДРОБНЫЕ, ЯСНЫЕ, ОПРЕДЕЛЕННЫЕ сообщения о проблемах. Чтобы сделать общение более эффективным, мы просим всех проверить, не существует ли вашей проблемы в списке поиска. Если вы найдете существующую проблему, пожалуйста, добавьте ваши детали в комментариях под существующим запросом, а не открывайте новый.

Чтобы сделать детали запроса как можно более стандартными, мы создали ШАБЛОН ЗАПРОСА для отправителей запросов. Пожалуйста, УБЕДИТЕСЬ, что вы следуете инструкциям для заполнения полей шаблона.

Есть много случаев, когда вы можете открыть запрос:

  • отчет об ошибке
  • запрос на новую функцию
  • проблемы производительности
  • предложение новой функции
  • дизайн функции
  • помощь требуется
  • документация не завершена
  • улучшение тестов
  • любые вопросы по проекту
  • и так далееТакже мы должны напомнить, что при заполнении нового запроса, пожалуйста, убедитесь, что вы удалили конфиденциальные данные из вашего сообщения. Конфиденциальные данные могут быть паролями, секретными ключами, сетевыми локациями, частными данными бизнеса и так далее.## Вклад в код и документацию

Каждое действие, направленное на улучшение проекта Serverless Devs, поощряется. На GitHub каждое улучшение для Serverless Devs может быть выполнено через PR (сокращение от pull request).

  • Если вы нашли опечатку, попробуйте её исправить!
  • Если вы нашли ошибку, попробуйте её исправить!
  • Если вы нашли избыточный код, попробуйте его удалить!
  • Если вы нашли отсутствующие тестовые случаи, попробуйте их добавить!
  • Если вы можете улучшить функцию, не сомневайтесь!
  • Если вы считаете код запутанным, попробуйте добавить комментарии, чтобы сделать его более понятным!
  • Если вы считаете код некрасивым, попробуйте его рефакторинг!
  • Если вы можете помочь улучшить документацию, это будет замечательно!
  • Если вы нашли ошибку в документации, просто исправьте её!
  • ...

В действительности невозможно перечислить все возможные улучшения. Просто помните одно правило:

НАМ ПОДОБРАЮТСЯ ЛЮБЫЕ ВАШИ PR.

Так как вы готовы улучшить Serverless Devs с помощью PR, мы рекомендуем вам ознакомиться с правилами PR здесь.

Подготовка рабочего пространства

Чтобы предложить PR, мы предполагаем, что у вас есть учетная запись GitHub. Тогда вы можете завершить подготовку в следующих шагах:1. FORK Serverless Devs в вашем репозитории. Чтобы это сделать, вам нужно нажать кнопку Fork справа от Serverless-Devs/Serverless-Devs главной страницы. Тогда вы окажетесь в вашем репозитории в https://github.com/<ваш-имя>/Serverless-Devs, где ваш-имя — ваше имя пользователя GitHub.

  1. CLONE ваш репозиторий на локальную машину для разработки. Используйте git clone git@github.com:<ваш-имя>/Serverless-Devs.git для клонирования репозитория на вашу локальную машину. Тогда вы сможете создать новые ветки для выполнения изменений, которые вы хотите внести.

  2. Установите удалённый репозиторий upstream на git@github.com:Serverless-Devs/Serverless-Devs.git с помощью следующих двух команд:

git remote add upstream git@github.com:Serverless-Devs/Serverless-Devs.git
git remote set-url --push upstream no-pushing

С этими настройками удаленного репозитория вы можете проверить конфигурацию вашего репозитория git следующим образом:

$ git remote -v
origin     git@github.com:<ваш-пользователь>/Serverless-Devs.git (fetch)
origin     git@github.com:<ваш-пользователь>/Serverless-Devs.git (push)
upstream   git@github.com:Serverless-Devs/Serverless-Devs.git (fetch)
upstream   no-pushing (push)

Добавление этого позволит легко синхронизировать локальные ветки с ветками upstream.

Определение веток

В настоящее время мы предполагаем, что каждое вклад в виде pull request направляется на ветку develop в Serverless Devs. Перед вкладом, осознание определения веток поможет очень многим.Как вкладчик, помните, что каждый вклад в виде pull request направляется на ветку develop. В проекте Serverless Devs есть несколько других веток, которые мы обычно называем ветками выпуска (например, 0.6.0, 0.6.1), ветками функций, ветками исправлений и веткой master.

При официальном выпуске версии будет создана ветка выпуска, названная с номером версии.

После выпуска мы будем объединять коммиты ветки выпуска в ветку master.

Когда мы обнаруживаем, что в определенной версии есть баг, мы решаем исправить его в более поздней версии или в конкретной версии исправления. Когда мы решаем исправить версию исправления, мы будем использовать ветку исправления, основанную на соответствующей ветке выпуска, выполнять ремонт и проверку кода, и объединять его в ветку develop и ветку master.

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

Правила коммитов

В Serverless Devs мы придерживаемся двух правил при коммитах:

Сообщение коммитаСообщение коммита поможет рецензентам лучше понять цель поданного pull request. Это также поможет ускорить процесс рецензирования кода. Мы поощряем вкладчиков использовать ЯСНОЕ сообщение коммита вместо нечеткого. В общем, мы поддерживаем следующий тип сообщения коммита:

  • docs: xxxx. Например, "docs: добавлены документы о установке кластера Serverless Devs".
  • feature: xxxx. Например, "feature: поддержка Oracle в режиме AT".
  • bugfix: xxxx. Например, "bugfix: устранена ошибка паники при вводе параметра nil".
  • refactor: xxxx. Например, "refactor: упрощено для повышения читаемости кода".
  • test: xxx. Например, "test: добавлен тестовый случай для функции InsertIntoArray".
  • другие читаемые и явные способы выражения.

С другой стороны, мы не рекомендуем вкладчикам коммитировать сообщения в таком виде:* фикс бага

  • обновление
  • добавление документации

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

Содержание коммита

Содержание коммита представляет собой все изменения, включенные в один коммит. Лучше всего включать в один коммит те изменения, которые могут быть полностью проверены рецензентом без помощи других коммитов. Другими словами, содержимое одного коммита может пройти CI, чтобы избежать путаницы в коде. Вкратце, есть три небольших правила, которые стоит помнить:

  • избегайте очень больших изменений в одном коммите;
  • содержимое каждого коммита должно быть завершено и проверяемым;
  • проверьте конфигурацию git (user.name, user.email) при коммите, чтобы убедиться, что он связан с вашим ID на GitHub;
  • при отправке PR, пожалуйста, добавьте краткое описание текущих изменений в файл X.X.X.md под папкой 'changes/'.

Кроме того, в части изменений кода мы рекомендуем всем вкладчикам ознакомиться с стилем кодирования Serverless Devs.

Независимо от того, речь идет о сообщении коммита или содержимом коммита, мы уделяем больше внимания проверке кода.PR — это единственный способ вносить изменения в файлы проекта Serverless Devs. Чтобы помочь рецензентам лучше понять вашу цель, описание PR не должно быть слишком подробным. Мы рекомендуем вкладчикам следовать шаблону PR для завершения pull request.## Вклад в тестовые случаи

Любые тестовые случаи приветствуются. В настоящее время тестовые случаи функций Serverless Devs имеют высокий приоритет.

  • Для юнит-тестов вам нужно создать файл теста с именем xxx-xxx.test.ts в директории тестов того же модуля. Рекомендуется использовать Jest как фреймворк для юнит-тестов.

  • Для интеграционных тестов вы можете разместить интеграционные тесты в директории тестов или в модуле Serverless Devs-test. Рекомендуется использовать тестовые фреймворки, связанные с моками.

Вклад в пакет

Для разработки пакета Serverless Devs, пожалуйста, обратитесь к руководству по разработке. После завершения разработки, пожалуйста, обратитесь к PR для более подробной информации.

Участвуйте для помощи в любом виде

Мы выбрали GitHub как основное место для сотрудничества в проекте Serverless Devs. Так что последние обновления Serverless Devs всегда доступны здесь. Хотя внесение изменений через PR является явным способом помощи, мы все равно призываем к использованию любых других способов.

  • отвечайте на вопросы других, если это возможно;
  • помогайте решать проблемы других пользователей;
  • помогайте проверять концепции PR других;
  • помогайте проверять коды других в PR;
  • обсуждайте Serverless Devs для уточнения деталей;
  • продвигайте технологию Serverless Devs за пределами GitHub;
  • пишите блоги о Serverless Devs и так далее.Коротко говоря, КАЖДАЯ ВОЗМОЖНАЯ ПОМОЩЬ ЯВЛЯЕТСЯ ВКЛАДОМ.

(Текст уже на русском языке и не требует перевода.)

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

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

1
https://api.gitlife.ru/oschina-mirror/serverless-devs-Serverless-Devs.git
git@api.gitlife.ru:oschina-mirror/serverless-devs-Serverless-Devs.git
oschina-mirror
serverless-devs-Serverless-Devs
serverless-devs-Serverless-Devs
master