freeCodeCamp/docs/i18n/Russian/how-to-open-a-pull-request.md

10 KiB
Raw Blame History

Как открыть Pull Request (PR)

Pull request позволяет отправлять изменения с вашего форка на GitHub на бесплатный CodeCamp.org репозиторий. Как только вы выполните изменения в коде, или вызовите код, вы должны следовать этим рекомендациям, чтобы отправить PR.

Подготовить хороший заголовок PR

Мы рекомендуем использовать обычные заголовки и сообщения для запросов на коммиты и pull. Контракт имеет следующий формат:

<type>([необязательный охват(ы)]): <description>

Например:

fix(learn): тесты для дела...while cycle challenge

При открытии Pull Request(PR) вы можете использовать ниже для определения типа, области действия (необязательно) и описания.

4.3.2 Тип:

Тип Когда выбрать
исправить Изменена или обновлена/улучшена функциональность, тесты, оглавление урока и т.д.
перенести Только если вы добавляете новые функции, тесты и т.д.
петь Изменения, не связанные с кодом, тестами или извержениями урока.
docs Изменения в /docs директории или рекомендации и т. д.

Область:

Вы можете выбрать область этого списка меток.

Пояснение:

Держите его коротким (менее 30 символов) и простым, вы можете добавить больше информации в поле описания PR и комментариев.

К примерам хороших PR-файлов относятся:

  • fix(a11y): улучшенный контраст строки поиска
  • feat: добавить больше тестов в html и css вызовы
  • fix(api,client): предотвращать ошибки CORS при отправке формы
  • docs(i18n): китайский перевод локальной установки

Предложить Pull Request

  1. Как только правки будут сделаны, вам будет предложено создать запрос на слияние на странице GitHub вашего форка.

    Изображение - Сравнить запрос на слияние на GitHub

  2. По умолчанию, все pull-запросы должны быть против репозитория freeCodeCamp, master ветки.

    Убедитесь, что базовый форк установлен в freeCodeCamp/freeCodeCamp при получении запроса на слияние.

    Изображение - Сравнение форков при создании Pull Request

  3. Отправьте запрос на слияние с вашей ветки на мастер- freeCodeCamp.

  4. В тексте вашего PR содержится более подробная информация об изменениях, которые вы сделали и почему.

    • Вам будет представлен шаблон Pull Request'а. Это контрольный список, который вы должны были следовать перед открытием Pull request.

    • Заполните детали по своему усмотрению. Эта информация будет рассмотрена, и участники будут решать, будет ли ваш запрос на слияние принят.

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

      Пример: Закрытие #123 закроет задачу 123

  5. Укажите, если вы протестировали на локальной копии сайта или нет.

    Это очень важно при внесении изменений, которые не просто редактируют содержимое текста, например документацию или описание проблемы. Примеры изменений, требующих локального тестирования, включают JavaScript, CSS или HTML, которые могут изменить функциональность или макет страницы.

Отзыв о pull-запросах

Поздравляем! 🎉 за создание PR и благодарит вас за то, что вы потратили время на участие.

Наши модераторы теперь посмотрите и оставьте отзыв. Пожалуйста, будьте терпеливы с другими модераторами и уважайте их время. Все Pull Request'ы рассматриваются в установленный срок.

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

[!TIP] Если вы хотите сделать больше запросов на слияние, мы рекомендуем вам прочитать сделанные изменения и синхронизировать рекомендации, чтобы избежать необходимости удаления ветки ветки.

Конфликтует на Pull Request

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

Чаще всего, вы не можете требовать перебазы, потому что мы используем все коммиты, Однако, если ребаз запрашивается здесь, это то, что вы должны делать.

Для обычных исправлений и возможностей

Когда вы работаете над регулярными ошибками и возможностями нашей ветки разработки master, вы можете сделать простой перебаз:

  1. Перебазируйте вашу локальную копию:

    git checkout <pr-branch>
    git pull --rebase upstream master
    
  2. Разрешать любые конфликты и добавлять/редактировать коммиты

    # Или
    git add .
    git commit -m "chore: урегулировать конфликты"
    
    # или
    git add .
    git коммит --change --no-edit
    
  3. Отправьте ваши изменения в PR

    git push --force origin <pr-branch>
    

Для предстоящей учебной программы и элементов

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

  1. Убедитесь, что ваш исходный код синхронизирован с локальным:

    git checkout master
    git fetch --all --prune
    git checkout next-python-projects
    git reset --hard upstream/next-python-projects
    
  2. Сделать резервную копию

    a. Удалите либо вашу локальную ветку после создания резервной копии (если она по-прежнему локальная):

    git checkout <pr-branch-name>
    
    # example:
    # git checkout feat/add-numpy-video-question
    
    git checkout -b <backup-branch-name>
    
    # example:
    # git checkout -b backup-feat/add-numpy-video-question
    
    git ветка -D <pr-branch-name>
    

    b. Или просто резервная копия вашей ветки Pr (если у вас нет локально):

    git checkout -b <backup-branch-name> origin/<pr-branch-name>
    
    # example:
    # git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
    
  3. Начать с чистого листа:

    git checkout -b <pr-branch-name> next-python-projects
    git cherry-pick <commit-hash>
    
  4. Разрешите конфликты и очистите, установите тесты запуска

    npm запуск очистить
    
    npm ci
    тест запуска npm:curriculum --superblock=<superblock-name>
    
    # пример:
    
    # npm запустить тест:curriculum --superblock=python-for-every
    
    
  5. Если все выглядит хорошо оттолкнуться к PR

    git push --force origin <pr-branch-name>