About rulesets

About rulesets

A ruleset is a named list of rules that applies to a repository, or to multiple repositories in an organization. You can have up to 75 rulesets per repository, and 75 organization-wide rulesets.

When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or GitHub Apps. For more information about granting bypass permissions, see Creación de conjuntos de reglas de un repositorio.

For organizations on the GitHub Enterprise plan, you can set up rulesets at the enterprise or organization level to target multiple repositories in your organization. See Administración de conjuntos de reglas para repositorios de la organización.

You can use rulesets to target branches or tags in a repository or to block pushes to a repository and the repository's entire fork network.

La omisión delegada para los conjuntos de reglas de inserción le permite controlar quién puede omitir la protección de inserción y qué inserciones bloqueadas deben permitirse.

Con la omisión delegada, los colaboradores a un repositorio deben solicitar “privilegios de omisión” al insertar confirmaciones que contienen contenido restringido. La solicitud se envía a un grupo designado de revisores, que aprueba o deniega la solicitud para omitir las reglas de inserción.

Si se aprueba la solicitud para omitir las reglas de inserción, el colaborador puede insertar la confirmación con contenido restringido. Si se deniega la solicitud, el colaborador debe eliminar el contenido de la confirmación (o las confirmaciones) que contiene el contenido restringido antes de volver a insertarlo.

Para configurar la omisión delegada, los propietarios de la organización o los administradores del repositorio crean primero una "lista de omisión". La lista de omisión incluye roles y equipos específicos, como los administradores del equipo o del repositorio, que supervisan las solicitudes para omitir la protección de inserción. Para más información, consulta Administración de conjuntos de reglas para repositorios de la organización y Acerca de los conjuntos de reglas.

Branch and tag rulesets

You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's feature branch that requires signed commits and blocks force pushes for all users except repository administrators.

For each ruleset you create, you specify which branches or tags in your repository, or which repositories in your organization, the ruleset applies to. You can use fnmatch syntax to define a pattern to target specific branches, tags, and repositories. For example, you could use the pattern releases/**/* to target all branches in your repository whose name starts with the string releases/. For more information on fnmatch syntax, see Creación de conjuntos de reglas de un repositorio.

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.

• 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.

About rulesets and protected branches

Rulesets work alongside any branch protection rules in a repository. Many of the rules you can define in rulesets are similar to protection rules, and you can start using rulesets without overriding any of your existing protection rules.

Rulesets have the following advantages over branch protection rules.

• Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch in your repository will be evaluated when someone interacts with that branch. See About rule layering.
• Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets.
• Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.
• You can create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address. See Reglas disponibles para conjuntos de reglas."

Using ruleset enforcement statuses

Al crear o editar el conjunto de reglas, puede utilizar los estados de obligatoriedad para configurar cómo se aplicará el conjunto de reglas.

Puede seleccionar cualquiera de los siguientes estados de obligatoriedad para el conjunto de reglas.

• Active: tu conjunto de reglas se aplicará después de la creación.
• Evaluate: tu conjunto de reglas no se aplicará, pero podrás supervisar las acciones que podrían infringir o no las reglas en la página "Rule Insights".
• Disabled: tu conjunto de reglas no se aplicará ni evaluará.

El uso del modo «Calcular» es una excelente opción para probar el conjunto de reglas sin aplicarlo. Puedes utilizar la página «Información sobre reglas» para ver si la contribución habría infringido la regla. Para más información, consulta Administración de conjuntos de reglas de un repositorio.

About rule layering

A ruleset does not have a priority. Instead, if multiple rulesets target the same branch or tag in a repository, the rules in each of these rulesets are aggregated. If the same rule is defined in different ways across the aggregated rulesets, the most restrictive version of the rule applies. As well as layering with each other, rulesets also layer with protection rules targeting the same branch or tag.

For example, consider the following situation for the my-feature branch of the octo-org/octo-repo repository.

• An administrator of the repository has set up a ruleset targeting the my-feature branch. This ruleset requires signed commits, and three reviews on pull requests before they can be merged.
• An existing branch protection rule for the my-feature branch requires a linear commit history, and two reviews on pull requests before they can be merged.
• An administrator of the octo-org organization has also set up a ruleset targeting the my-feature branch of the octo-repo repository. The ruleset blocks force pushes, and requires one review on pull requests before they can be merged.

The rules from each source are aggregated, and all rules apply. Where multiple different versions of the same rule exist, the result is that the most restrictive version of the rule applies. Therefore, the my-feature branch requires signed commits and a linear commit history, force pushes are blocked, and pull requests targeting the branch will require three reviews before they can be merged.

Next steps

Next, learn how to communicate important information with members of your enterprise using READMEs. See Create a README for your enterprise.