Рекомендации по запросу на вытягивание

Рекомендации по созданию запросов на вытягивание

При создании запроса на вытягивание выполните несколько рекомендаций для более гладкого процесса проверки. Сведения о создании запроса на вытягивание см. в разделе "Создание запроса на включение изменений".

Запись небольших PR

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

Сначала просмотрите собственный запрос на вытягивание

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

Предоставление контекста и рекомендаций

Напишите четкие заголовки и описания для запросов на вытягивание, чтобы рецензенты могли быстро понять, что делает запрос на вытягивание. В тексте запроса на вытягивание включите:

• Назначение запроса на вытягивание
• Общие сведения о том, что изменилось
• ссылки на любой дополнительный контекст, например отслеживание проблем или предыдущих бесед

Чтобы помочь рецензентам, поделитесь нужным типом отзывов. Например, вам нужен быстрый взгляд или более глубокая критика?

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

Рекомендации по управлению запросами на вытягивание

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

Использование шаблонов запросов на вытягивание

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

Шаблоны запросов на вытягивание можно использовать для стандартизации процесса проверки репозитория. Например, можно включить список задач, которые нужно выполнить авторам перед объединением запросов на вытягивание, добавив список задач в шаблон. Дополнительные сведения см. в разделе "Сведения о списках задач".

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

Определение владелец кода

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

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

Использование защищенная ветвь

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

Использование наборов правил push-уведомлений

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

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

Push-наборы правил позволяют выполнять следующие действия.

• Ограничить пути к файлам: запретить фиксации, включающие изменения в указанные пути к файлам.

  Для этого можно использовать fnmatch синтаксис. Например, ограничение, предназначенное для test/demo/**/* предотвращения отправки в файлы или папки в test/demo/ каталоге. Ограничение, предназначенное для test/docs/pushrules.md предотвращения отправки pushrules.md в файл в каталоге test/docs/ . Дополнительные сведения см. в разделе Создание наборов правил для репозитория.

• Ограничить длину пути к файлу: запретить фиксации, включающие пути к файлам, превышающие указанное ограничение символов от отправки.

• Ограничение расширений файлов. Запретить отправку фиксаций, включающих файлы с указанными расширениями файлов.

• Ограничение размера файла. Запретить отправку фиксаций, превышающих указанное ограничение размера файла.

Сведения о наборе правил push для вилированных репозиториев

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

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

Дополнительные сведения см. в разделе Сведения о наборе правил.

Использование автоматизированных средств для просмотра стиля кода

Используйте автоматизированные средства, такие как linters, в запросах на вытягивание репозитория, чтобы обеспечить согласованность стилей и сделать код более понятным. Использование автоматизированных средств для перехвата небольших проблем, таких как опечатки или стилизация, оставляет больше времени для рецензентов сосредоточиться на веществе запроса на вытягивание.

Например, можно использовать GitHub Actions для настройки кода linters, которые могут выполняться при запросах на вытягивание в рамках рабочего процесса непрерывной интеграции (CI). Дополнительные сведения см. в разделе Сведения о непрерывной интеграции.