Skip to main content

Acerca de los conjuntos de reglas

Los conjuntos de reglas ayudan a controlar cómo los usuarios pueden interactuar con ramas y etiquetas de un repositorio.

¿Quién puede utilizar esta característica?

Cualquier persona con acceso de lectura a un repositorio puede ver los conjuntos de reglas del repositorio. Las personas con acceso de administrador a un repositorio o un rol personalizado con el permiso "editar reglas de repositorio", pueden crear, editar y eliminar conjuntos de reglas para un repositorio.

Los conjuntos de reglas están disponibles en los repositorios públicos con GitHub Free y GitHub Free para organizaciones, y en los repositorios públicos y privados con GitHub Pro, GitHub Team y GitHub Enterprise Cloud. Para más información, consulta "Planes de GitHub".

Acerca de los conjuntos de reglas

Un conjunto de reglas es una lista de reglas con nombre que se aplican a un repositorio. Puedes crear conjuntos de reglas para controlar cómo las personas pueden interactuar con ramas y etiquetas seleccionadas en un repositorio. Puedes controlar aspectos como quién puede insertar confirmaciones en una rama determinada, o quién puede eliminar una etiqueta o cambiarle el nombre. Por ejemplo, podrías configurar un conjunto de reglas para la rama feature del repositorio que requiere confirmaciones firmadas y bloquea las inserciones forzadas para todos los usuarios, excepto los administradores del repositorio.

Para cada conjunto de reglas que crees, debes especificar a qué ramas o etiquetas del repositorio se aplica el conjunto de reglas. Puedes usar la sintaxis fnmatch para definir un patrón dirigido a ramas y etiquetas específicos. Por ejemplo, podrías usar el patrón releases/**/* para dirigirte a todas las ramas del repositorio cuyo nombre comienza por la cadena releases/. Para obtener más información sobre fnmatch, consulta "Creación de conjuntos de reglas de un repositorio."

Al crear un conjunto de reglas, puedes permitir que determinados usuarios omitan las reglas del conjunto de reglas. Pueden ser usuarios con un rol determinado, como el administrador del repositorio, o bien pueden ser equipos o GitHub Apps específicos.

Hay un límite de 75 conjuntos de reglas por repositorio.

Acerca de los conjuntos de reglas, las ramas protegidas y las etiquetas protegidas

Los conjuntos de reglas funcionan junto con las reglas de protección de ramas y las reglas de protección de etiquetas de un repositorio. Muchas de las reglas que puedes definir en conjuntos de reglas son similares a las reglas de protección y puedes empezar a usar conjuntos de reglas sin invalidar ninguna de las reglas de protección existentes.

Además, puede importar reglas de protección de etiquetas existentes en conjuntos de reglas de repositorio. Esto implementará las mismas protecciones de etiquetas que tienes actualmente para el repositorio. Para más información, consulta "Configuración de reglas de protección de etiquetas".

Los conjuntos de reglas tienen las siguientes ventajas sobre las reglas de protección de ramas y etiquetas.

  • A diferencia de las reglas de protección, se pueden aplicar varios conjuntos de reglas al mismo tiempo, por lo que puedes estar seguro de que todas las reglas destinadas a una rama o etiqueta del repositorio se evaluarán cuando alguien interactúe con esa rama o etiqueta. Para obtener más información, consulta "Acerca de las capas de reglas."
  • Los conjuntos de reglas tienen estados, por lo que puedes administrar fácilmente qué conjuntos de reglas están activos en un repositorio sin necesidad de eliminar conjuntos de reglas.
  • Cualquier persona con acceso de lectura a un repositorio puede ver los conjuntos de reglas activos del repositorio. Esto significa que un desarrollador puede comprender por qué utiliza una regla, o un auditor puede comprobar las restricciones de seguridad del repositorio, sin requerir el acceso del administrador al repositorio.

Además, para las organizaciones de un plan GitHub Enterprise, puedes hacer lo siguiente con los conjuntos de reglas.

  • Configura rápidamente conjuntos de reglas en el nivel de organización para dirigirte a varios repositorios de la organización. Para obtener más información, consulta "Administración de conjuntos de reglas para repositorios de la organización" en la documentación de GitHub Enterprise Cloud.
  • Crea reglas adicionales para controlar los metadatos de las confirmaciones que se escriben en un repositorio, como el mensaje de confirmación y la dirección de correo electrónico del autor. Para obtener más información, consulta "Reglas disponibles para conjuntos de reglas" en la documentación de GitHub Enterprise Cloud.
  • Usa un estado "Evaluar" para probar un conjunto de reglas antes de activarlo y usa una página de información para ver a qué acciones de usuario afectan las reglas. Para obtener más información, consulta "Administración de conjuntos de reglas de un repositorio" en la documentación de GitHub Enterprise Cloud.

Acerca de las capas de reglas

Un conjunto de reglas no tiene prioridad. En su lugar, si varios conjuntos de reglas tienen como destino la misma rama o etiqueta en un repositorio, se agregan las reglas de cada uno de estos conjuntos de reglas. Si la misma regla se define de maneras diferentes en los conjuntos de reglas agregados, se aplica la versión más restrictiva de la regla. Además superponerse entre sí, los conjuntos de reglas también se superponen con reglas de protección que tienen como destino la misma rama o etiqueta.

Por ejemplo, considera la siguiente situación para la rama my-feature del repositorio octo-org/octo-repo.

  • Un administrador del repositorio ha configurado un conjunto de reglas destinado a la rama my-feature. Este conjunto de reglas requiere confirmaciones firmadas y tres revisiones en las solicitudes de cambios para poder combinarlas.
  • Una regla de protección de rama existente para la rama my-feature requiere un historial de confirmaciones lineales y dos revisiones en las solicitudes de cambios antes de que se puedan combinar.

Las reglas de cada origen se agregan y se aplican todas. Cuando existen varias versiones diferentes de la misma regla, el resultado es que se aplica la versión más restrictiva de la regla. Por lo tanto, la rama my-feature requiere confirmaciones firmadas y un historial de confirmaciones lineales y las solicitudes de cambios destinadas a la rama requerirán tres revisiones antes de poder combinarlas.