Как отправить запросы на слияние

Чтобы внести изменения в содержимое, отправьте запрос на вытягивание (PR) из форка. Прежде чем пулл-реквест можно будет объединить, его необходимо проверить. Для наилучших результатов просмотрите редакционный контрольный список перед отправкой pull request.

Использование ветвей Git

Ветвь по умолчанию для PowerShell-Docs — это main ветвь. Перед публикацией изменения, внесенные в рабочие ветви, объединяются в ветвь main. Ветка main объединяется в ветку live в будние дни в 15:00 (тихоокеанское время). Ветвь live содержит содержимое, опубликованное в learn.microsoft.com.

Перед началом любых изменений создайте рабочую ветвь в локальной копии репозитория PowerShell-Docs. При локальной работе необходимо синхронизировать локальный репозиторий перед созданием рабочей ветви. Рабочая ветвь должна быть создана из копии up-to-date ветви main .

Все пулл-реквесты должны направляться в ветку main. Не отправляйте изменения в ветвь live. Изменения, внесенные в ветвь main, объединяются в live, перезаписав все изменения, внесенные в live.

Сделайте процесс pull-запросов удобнее для всех

Чем проще и более сфокусирован ваш PR, тем быстрее его можно проверить и объединить.

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

Избегайте создания PR, содержащих несвязанные изменения. Разделите незначительные обновления существующих статей из новых статей или основных перезаписей. Работайте над этими изменениями в отдельных рабочих ветвях.

Массовые изменения создают PR с большим количеством измененных файлов. Ограничьте количество PR до не более 50 измененных файлов. Большие PR трудно проверить и более склонны к возникновению ошибок.

Переименование или удаление файлов

При переименовании или удалении файлов проблема должна быть связана с PR. Необходимо обсудить вопрос о переименовании или удалении файлов.

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

Избегайте редактирования файлов конфигурации репозитория

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

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

• *.yml
• .github/**
• .localization-config
• .openpublishing*
• LICENSE*
• reference/docfx.json
• reference/mapping/**
• tests/**
• ThirdPartyNotices
• tools/**

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

Использование шаблона PR

При создании PR шаблон автоматически вставляется в текст PR. Выглядит следующим образом:

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

В разделе "Сводка по PR" напишите краткую сводку по изменениям и перечислите все связанные проблемы по их номеру проблемы, например #1234. Если ваш PR исправляет или решает проблему, используйте функцию автоматического закрытия GitHub, чтобы проблема автоматически закрывалась при объединении вашего PR.

Просмотрите элементы в разделе "Контрольный список PR" и отмечайте их по мере выполнения каждого из них. Необходимо следовать указаниям и проверять каждый элемент, чтобы команда одобрила ваш PR.

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

Комментарий к ожиданиям

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

Служба проверки PR документации

Служба проверки pr документации — это приложение GitHub, которое выполняет правила проверки изменений. Необходимо устранить любые ошибки или предупреждения, сообщаемые службой проверки.

Ниже описано поведение проверки.

1. Вы отправляете PR.

2. В комментарии на GitHub, указывающем статус проверок, включенных в репозитории. В этом примере включены две проверки: "Проверка коммита" и "OpenPublishing.Build":

   

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

3. Дополнительные сведения см. в разделе " Дополнительные сведения". На странице сведений отображаются все проверки, которые не удалось выполнить, и содержатся сведения о том, как устранить проблемы.

4. При успешной проверке в pr добавляется следующий комментарий:

   

При проверке PR может потребоваться внести изменения или исправить предупреждающие сообщения проверки. Команда PowerShell-Docs поможет вам понять ошибки проверки и редакционные требования.

Действия GitHub

Несколько различных действий GitHub запускаются против ваших изменений, чтобы проверить их и предоставить контекст вам и рецензентам.

Проверка контрольного списка

Если ваш PR не находится в черновике и не имеет с префиксом WIP, GitHub Action проверяет ваш PR, чтобы убедиться, что вы выбрали каждый элемент контрольного списка в шаблоне PR. Администраторы не будут проверять или объединять ваш PR до тех пор, пока вы не завершите контрольный список. Контрольный список элементов является обязательным.

Проверка подлинности

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

Только администраторы репозитория могут использовать ветвь live или изменять файлы конфигурации репозитория.

Отчеты об изменении версий содержимого

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

Этот отчет может показать, есть ли другие версии файлов, которые необходимо обновить в этом PR.

Чтобы найти отчет о версиях содержимого для вашего PR:

1. Выберите вкладку "Проверки" на странице PR.
2. Выберите задание "Отчеты" из списка заданий.
3. Нажмите на кнопку "..." в правом верхнем углу.
4. Выберите "Просмотреть сводку задания".

Дальнейшие действия

Руководство по стилюPowerShell-Docs

Дополнительные ресурсы

Как мы управляем pull requests