Управление пулл-реквестами

В статье описывается, как мы управляем пулл-реквестами в репозитории PowerShell-Docs. Эта статья предназначена как пособие для членов команды PowerShell-Docs. Мы публикуем эту информацию здесь, чтобы обеспечить прозрачность процесса для наших общедоступных участников.

Лучшие практики

• Запрос проверки. Человек, отправляющий PR, не должен объединять PR без взаимной проверки.
• Назначьте рецензента, когда PR отправлен. Раннее назначение позволяет рецензенту реагировать раньше с редакционными замечаниями.
• Используйте примечания, чтобы описать характер отправленного изменения. Например, если изменение является незначительным, объясните это изменение и что вам не нужен полный технический обзор. Не забудьте @mention рецензента.
• Используйте функцию предложения примечания, чтобы упростить для автора принятие предлагаемых изменений. Дополнительные сведения см. в разделе "Просмотр предлагаемых изменений" в pull request.

Этапы процесса PR

1. Автор: создать PR
   • Заполнение шаблона PR
   • Свяжите все проблемы, решенные с помощью PR
   • Используйте функцию автозакрытия GitHub, чтобы закрыть проблему.
   • Прорабатывайте и отмечайте каждый элемент в контрольном списке
2. Автор: Назначить рецензента коллегиального уровня
3. Рецензент: корректирует и комментирует (при необходимости)
4. Автор: учитывать отзывы
5. Оба: просмотр предварительной отрисовки
6. Оба: просмотр отчета о проверке — исправление предупреждений и ошибок
7. Рецензент: Пометить отзыв "Утверждено"
8. Средство поддержки репозитория: слияние PR

Контрольный список рецензента содержимого

См. контрольный список редакции для более полного списка.

• Вычитка для проверки грамматики, стиля, краткости, технической точности
• Убедитесь, что примеры по-прежнему применяются к целевой версии
• Проверка предварительной отрисовки
• Проверьте метаданные — ms.date, удалите ms.assetid и убедитесь, что обязательные поля заполнены.
• Проверка правильности markdown
  • См. руководство по стилю для правил форматирования, относящихся к содержимому
• Переорганизуйте примеры следующим образом:
  • Вводный абзац
  • код и выходные данные;
  • Подробное описание кода (по мере необходимости)
• Проверка гиперссылок для точности
  • Замена или удаление ссылок TechNet/MSDN
  • Обеспечение минимального количества перенаправлений на целевой объект
  • Обеспечьте использование HTTPS
  • Правильный тип ссылки
    • Ссылки на файлы для локальных файлов
    • ССЫЛКИ НА URL-адреса файлов за пределами набора документов
  • Удаление локалей из URL-адресов
  • Упрощение URL-адресов, указывающих на learn.microsoft.com
• Проверка правильности версионного содержимого по всем версиям
  • Ознакомьтесь с отчётом об изменениях версии контента

Процесс слияния ветви

Ветвь main — это единственная ветвь, в liveкоторую следует объединиться. Слияния из кратковременных (рабочих) ветвей должны быть объединены перед слиянием в main.

Контрольный список слияния PR

• Проверка содержимого завершена
• Правильная целевая ветвь для изменения
• Конфликтов слияния нет
• Все этапы проверки и сборки успешно завершены
  • Предупреждения и предложения должны быть исправлены (см. заметки об исключениях)
  • Нет неработающих ссылок
  • Действие контрольного списка запущено и успешно завершено
  • Если проверка авторизации была активирована, она прошла
• Объединить согласно таблице

Примечания.

Можно игнорировать следующие предупреждения:

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

При слиянии PR изменяется HEAD целевой ветви. Все открытые PR, основанные на предыдущем HEAD, в настоящее время устарели. У хранителя есть право переопределить предупреждения слияния и объединить устаревший PR в GitHub. Слияние устаревшего PR безопасно, если ранее объединенные PR не касались одинаковых файлов.

Чтобы обновить PR, нажмите кнопку "Обновить ветвь ". Выберите "Обновить" с параметром повторной базы данных. Дополнительные сведения см. в источнике "Обновление ветки pull request".

Публикация в реальном времени

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

• Ветвь main объединяется с live каждым будним днем в 3 вечера PST.
• Ветвь main должна быть объединена с live после любого значительного изменения.
  • Изменения в 50 или более файлов
  • После объединения ветви выпуска
  • Изменения конфигураций репозитория или набора документов (docfx.json, конфигурации OPS, скрипты сборки и т. д.)
  • Изменения в файле перенаправления
  • Изменения в оглавлении
  • После объединения ветви «проект» (переупорядочение содержимого, массовое обновление и т. д.)