# Managing and standardizing pull requests

Manage and standardize pull requests using templates, code owners, protected branches, rulesets, and automated tools for consistent and secure repository contributions.

If you maintain a repository, you can use GitHub features to make pull requests more consistent and easier to review. Standardization helps contributors know what information to provide, helps reviewers focus on the right changes, and helps protect important branches from accidental or risky merges.

## Using pull request templates

Pull request templates help contributors provide the context your project needs for review. A template can prompt authors to explain the purpose of the change, link related issues, include testing notes, or complete a checklist before requesting review.

Templates are useful when many contributors open pull requests or when your project has review expectations that should be visible every time. See [Crear una plantilla de pull request para tu repositorio](/es/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository), [Acerca de las listas de tareas](/es/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists), and [Vincular una solicitud de cambios a una propuesta](/es/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue).

## Defining code owners

Code owners identify the people or teams responsible for specific files or directories. When a pull request changes owned code, GitHub can automatically request a review from the right owners.

Code owners help route reviews to people with the right context. They are especially useful for sensitive areas such as security files, deployment configuration, or shared libraries. See [Acerca de los propietarios de código](/es/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

## Using protected branches

Protected branches help keep important branches, such as `main`, stable. They can require conditions such as passing status checks, signed commits, or approving reviews before a pull request can merge.

Use protected branches when a branch represents production code, a release line, or another important source of truth. See [Acerca de las ramas protegidas](/es/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).

## Using rulesets

Rulesets let you enforce repository policies across branches and tags. They can require status checks, workflows, pull request reviews, or other conditions before changes are accepted.

Rulesets are useful when you want consistent rules across multiple branches or when you want to combine review requirements with automated security checks, such as dependency review or code scanning merge protection. See [Acerca de los conjuntos de reglas](/es/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), [Aplicación de la revisión de dependencias en una organización](/es/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review), and [Establecimiento de la protección contra la fusión de análisis de códigos](/es/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/set-merge-protection).

## Using push rulesets

Con los conjuntos de reglas de inserción, puedes bloquear las inserciones en un repositorio privado o interno y la red de bifurcación completa del repositorio en función de extensiones de archivo, longitudes de ruta de acceso de archivo, rutas de acceso de archivo y carpetas y tamaños de archivo.

Las reglas de inserción no requieren ningún destino de rama porque se aplican a cada inserción en el repositorio.

Los conjuntos de reglas de inserción te permiten:

* **Restringir rutas de acceso de archivo**: impide que se inserte la inserción de confirmaciones que incluyan cambios en las rutas de acceso de archivo especificadas.

  Para ello, puedes usar la sintaxis `fnmatch`. Por ejemplo, una restricción dirigida `test/demo/**/*` evita las inserciones en archivos o carpetas del directorio `test/demo/`. Un destino de restricción `test/docs/pushrules.md` impide que las inserciones se inserten específicamente en el archivo `pushrules.md` del directorio `test/docs/`. Para más información, consulta [Creación de conjuntos de reglas de un repositorio](/es/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax).
* **Restringir la longitud de la ruta de acceso del archivo**: impide que se inserten confirmaciones que incluyan rutas de acceso de archivo que superen un límite de caracteres especificado.
* **Restringir extensiones de archivo**: impide que las confirmaciones que incluyan archivos con extensiones de archivo especificadas se inserten.
* **Restringir el tamaño del archivo**: evita que se inserten confirmaciones que superen un límite de tamaño de archivo especificado.

### Acerca de los conjuntos de reglas de inserción para repositorios bifurcados

Las reglas de inserción se aplican a toda la red de bifurcación de un repositorio, lo que garantiza que todos los puntos de entrada del repositorio están protegidos. Por ejemplo, si bifurcas un repositorio con conjuntos de reglas de inserción habilitados, los mismos conjuntos de reglas de inserción también se aplicarán al repositorio bifurcada.

En el caso de un repositorio bifurcada, las únicas personas que tienen permisos de omisión para una regla de inserción son las personas que tienen permisos de omisión en el repositorio raíz.

Push rulesets help block risky content before it enters the repository. See [Acerca de los conjuntos de reglas](/es/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).

## Using automated tools to review code styling

Automated tools, such as linters and formatters, help keep code style consistent across pull requests. They can catch small issues automatically so reviewers can focus on design, correctness, and maintainability.

You can run these tools as part of a continuous integration workflow with GitHub Actions. See [Integración continua](/es/actions/get-started/continuous-integration).