Reglas disponibles para conjuntos de reglas

Puedes crear conjuntos de reglas de ramas o etiquetas para controlar cómo los usuarios pueden interactuar con ramas y etiquetas seleccionadas en un repositorio. También puedes crear conjuntos de reglas de inserción para bloquear inserciones en un repositorio privado o interno y en toda la red de bifurcación del repositorio.

Al crear un conjunto de reglas, puede permitir que determinados usuarios omitan las reglas del conjunto de reglas. Pueden ser usuarios con determinados roles, equipos específicos o GitHub Apps.

En el caso de los conjuntos de reglas de inserción, los permisos de omisión se aplican a un repositorio y a toda la red de bifurcación del repositorio. Esto significa que los únicos usuarios que pueden omitir este conjunto de reglas para cualquier repositorio de toda la red de bifurcación de este repositorio son los usuarios que pueden omitir este conjunto de reglas en el repositorio raíz.

Para obtener más información sobre cómo crear conjuntos de reglas y permisos de omisión, consulta Creación de conjuntos de reglas de un repositorio.

Restringir creaciones

Si se selecciona, solo los usuarios con permisos de omisión pueden crear ramas o etiquetas cuyo nombre coincida con el patrón que especifiques.

Restringir actualizaciones

Si se selecciona, solo los usuarios con permisos de omisión pueden enviar cambios a las ramas o etiquetas cuyo nombre coincida con el patrón que especifiques.

Restringir eliminaciones

Si se selecciona, solo los usuarios con permisos de omisión pueden eliminar las ramas o etiquetas cuyo nombre coincida con el patrón que especifiques. Esta regla está seleccionada de manera predeterminada.

Requerir un historial linear

El requerir un historial de confirmaciones linear previene que los colaboradores inserten confirmaciones de fusión en las ramas o etiquetas de destino. Esto significa que cualquier solicitud de extracción fusionada con la rama o etiqueta debe utilizar una fusión mediante una combinación con "squash" o una fusión mediante cambio de base. Un historial de confirmaciones estrictamente linear puede ayudar a los equipos a revertir los cambios con mayor facilidad. Para obtener más información sobre los métodos de fusión, consulta Acerca de las integraciones de pull requests.

Antes de poder requerir un historial de confirmaciones linear, tu repositorio deberá permitir fusiones combinadas o fusiones de rebase. Para más información, consulta Configurar fusiones de solicitudes de extracción.

Requerir una cola de fusión

Puede requerir que las combinaciones se realicen con una cola de combinación en el nivel de repositorio. Para obtener más información sobre las colas de fusión, consulta Combinación de una solicitud de incorporación de cambios con una cola de fusión mediante combinación.

Configuración adicional

Puede configurar varias opciones para la regla de cola de combinación.

•           **Método de combinación:** método que se usa al combinar los cambios de las solicitudes de incorporación de cambios.
  

•           **Simultaneidad de compilación:** limite el número de solicitudes de incorporación de cambios en cola que solicitan comprobaciones y ejecuciones de flujo de trabajo al mismo tiempo.
  

  • Esta configuración controla cuándo envía la cola de combinación el merge_group.checks_requested evento de webhook, que activa los flujos de trabajo de GitHub Actions configurados para ejecutarse en merge_group. Para más información, consulta Eventos y cargas de webhook.
  • Por ejemplo, si se agregan 5 solicitudes de incorporación de cambios a la cola y la configuración de simultaneidad de compilación es 3, la cola de combinación distribuirá el evento checks_requested a las 3 primeras solicitudes de incorporación de cambios. Cuando reciba un resultado para una de esas solicitudes de incorporación de cambios, la cola de combinación enviará el evento para la 4.ª solicitud de cambios, etc.

•         **Tamaño mínimo/máximo del grupo:** La cantidad de pull requests que se fusionarán en un grupo.
  

•           **Tiempo de espera para cumplir el tamaño mínimo del grupo (minutos):** tiempo que esperará la cola de combinación después de añadir la primera solicitud de cambios para que se cumpla el tamaño mínimo del grupo. Una vez transcurrido este tiempo, se omitirá el tamaño mínimo del grupo y se combinará un grupo más pequeño.
  

•         **Requerir que todas las entradas de cola pasen las comprobaciones necesarias**:
  

  • Cuando esta configuración está habilitada, los distintos elementos del grupo de combinación deben pasar todas las comprobaciones necesarias.
  • Cuando esta configuración está deshabilitada, solo el commit en la cabeza del grupo de fusión, es decir, el commit que contiene los cambios de todos los pull requests del grupo, debe pasar las verificaciones necesarias para fusionarse.

•         **Tiempo de espera para comprobación de estado (minutos):** tiempo máximo de una comprobación de estado necesaria para informar de una conclusión. Una vez transcurrido este tiempo, se supone que las comprobaciones que no han notificado una conclusión han fallado.
  

Requerir que los despliegues tengan éxito antes de la fusión

Puede exigir que los cambios se implementen correctamente en entornos específicos antes de poder combinar una rama. Por ejemplo, puede usar esta regla para asegurarse de que los cambios se implementan correctamente en un entorno de ensayo antes de que se combinen en la rama predeterminada.

Requerir confirmaciones firmadas

Al habilitar la firma de confirmación obligatoria en una rama, los colaboradores solo pueden insertar confirmaciones que se hayan firmado y comprobado en la rama. Para más información, consulta Acerca de la verificación de firma de confirmación.

Las reglas y conjuntos de reglas de protección de ramas se comportan de forma diferente al crear una rama: con conjuntos de reglas, solo se comprueban las confirmaciones que no son accesibles desde otras ramas, mientras que con las reglas de protección de ramas, no se comprueban las confirmaciones firmadas a menos que restrinjas las inserciones que crean ramas coincidentes. Con ambas formas, al actualizar una rama, seguimos comprobando todas las confirmaciones en el intervalo especificado, incluso si se puede acceder a una confirmación desde otras ramas.

Además, con ambos modos se usa verified_signature? para confirmar si una confirmación tiene una firma válida. Si no es así, no se acepta la actualización.

Siempre puede subir confirmaciones locales a la rama si estas se firmaron y verificaron. Sin embargo, no puede combinar solicitudes de incorporación de cambios en la rama en GitHub. Puede combinar las solicitudes de incorporación de cambios localmente. Para más información, consulta Revisar solicitudes de extracción localmente.

Requerir un 'pull request' antes de fusionar

Puede requerir que todos los cambios en la rama de destino estén asociados a una solicitud de cambios. No necesariamente se tiene que aprobar el pull request, pero debe estar abierto.

Configuración adicional

Los administradores de repositorios o roles personalizados con el permiso "editar reglas de repositorio" pueden requerir que todas las solicitudes de incorporación de cambios reciban un número específico de revisiones de aprobación antes de que alguien combine la solicitud de incorporación de cambios con una rama protegida. Puedes requerir revisiones de aprobación de personas con permisos de escritura en el repositorio o de un propietario de código designado.

Si habilitas las revisiones requeridas, los colaboradores solo podrán subir los cambios a una rama mediante una solicitud de cambios que se encuentre aprobada por el total de revisores requeridos con permisos de escritura.

Si alguien elige la opción Solicitar cambios en una revisión, tendrá que aprobar la solicitud de cambios antes de que se pueda combinar. Si un revisor que solicita cambios en una solicitud de cambios no está disponible, cualquiera con permisos de escritura para el repositorio podrá descartar la revisión que está haciendo el bloqueo.

Incluso después de que todos los revisores hayan aprobado una solicitud de cambios, los colaboradores no pueden fusionar la solicitud de cambios si hay otra solicitud de cambios abierta que tenga una rama de encabezado que apunte a la misma confirmación y tenga revisiones rechazadas o pendientes. Alguien con permisos de escritura debe aprobar o descartar primero la revisión que está causando el bloqueo en el resto de las solicitudes de cambios.

También puede optar por descartar aprobaciones de solicitud de cambios obsoletas cuando se insertan confirmaciones que afectan a la diferencia en la solicitud de cambios. GitHub registra el estado de la diferencia en el momento en que se aprueba una solicitud de cambios. Este estado representa el conjunto de cambios que el revisor aprobó. Si el estado de la diferencia cambia (por ejemplo, porque un colaborador realiza nuevos cambios en la rama de la solicitud de extracción o hace clic en Actualizar rama, o bien porque se fusiona una solicitud de extracción relacionada en la rama de destino), la revisión de aprobación se descarta como obsoleta, y la solicitud de extracción no se puede fusionar hasta que alguien apruebe nuevamente el trabajo. Para información sobre la rama de destino, consulta Acerca de las solicitudes de incorporación de cambios.

Opcionalmente, puede elegir el requerir revisiones de los propietarios del código. Si lo haces, el propietario de código deberá aprobar cualquier solicitud de cambios que modifique el contenido antes de que la solicitud de cambios pueda fusionarse en la rama protegida. Ten en cuenta que si el código tiene varios propietarios, una aprobación de cualquiera de los propietarios del código será suficiente para cumplir este requisito. Para más información, consulta Acerca de los propietarios de código.

Opcionalmente, puede requerir una aprobación de alguien que no sea la última persona para insertar en una rama antes de que se pueda combinar una solicitud de incorporación de cambios. Esto significa que al menos otro revisor autorizado aprobó los cambios. Por ejemplo, el "último revisor" puede comprobar que el conjunto más reciente de cambios incorpora comentarios de otras revisiones y no agrega contenido nuevo no revisado.

En el caso de solicitudes de extracción complejas que requieren muchas revisiones, exigir la aprobación de alguien que no sea la última persona en hacer el push puede ser un compromiso que evite la necesidad de descartar todas las revisiones obsoletas: con esta opción, las revisiones "obsoletas" no se descartan y la solicitud de extracción permanece aprobada siempre y cuando la apruebe alguien que no sea quien hizo los cambios más recientes. A los usuarios que ya han revisado una solicitud de incorporación de cambios se les puede volver a aprobar después de la inserción más reciente para cumplir este requisito. Si le preocupa que "se secuestren" las solicitudes de cambios (donde el contenido no aprobado se agrega a las solicitudes de cambios aprobadas), es más seguro descartar las revisiones obsoletas.

Opcionalmente, puede requerir que se resuelvan todos los comentarios del pull request antes de que se pueda fusionar con una rama. Esto garantiza que todos los comentarios se traten o reconozcan antes de fusionar.

Opcionalmente, puedes requerir un tipo de fusión: merge, squash o rebase. Esto significa que las ramas objetivo solo pueden ser fusionadas según el tipo permitido. Además, si el repositorio ha deshabilitado un método de fusión mediante combinación y el conjunto de reglas requería un método diferente, la fusión mediante combinación se bloqueará. Consulta Acerca de los métodos de combinación en GitHub.

Requerir que las comprobaciones de estado pasen antes de la combinación

Las comprobaciones de estado requeridas garantizan que todas las pruebas de integración continua (CI) requeridas sean aprobadas antes de que los colaboradores puedan realizar cambios en una rama o etiqueta cuyo destino sea tu conjunto de reglas. Las comprobaciones de estado necesarias pueden ser comprobaciones o estados. Para más información, consulta Acerca de las verificaciones de estado.

Puede usar la API de estado de confirmación para permitir que los servicios externos marquen las confirmaciones con un estado adecuado. Para más información, consulta Puntos de conexión de la API de REST para estados de confirmaciones.

Después de habilitar las comprobaciones de estado requeridas, cualquier comprobación de estado deberá pasar antes de que los colaboradores puedan fusionar los cambios en la rama o etiqueta. Opcionalmente, puede seleccionar "No requerir comprobaciones de estado en la creación" si desea permitir la creación de ramificaciones independientemente del resultado de la comprobación de estado.

Cualquier persona o integración con permisos de escritura en un repositorio puede configurar el estado de cualquier verificación de estado en el repositorio, pero en algunos casos, podrías querer que solo se acepte una verificación de estado desde una GitHub App específica. Cuando añade una regla comprobación de estado requerida, puede seleccionar una aplicación como la fuente de actualizaciones de estado esperada. La aplicación debe instalarse en el repositorio con el permiso statuses:write, debe haber enviado recientemente una ejecución de comprobación y debe estar asociada a una comprobación de estado requerida preexistente en el conjunto de reglas. Si otra persona o integración configura el estado, no se permitirá la fusión. Si seleccionas "cualquier fuente", aún puedes comprobar manualmente el autor de cada estado, que se enumeran en el cuadro de combinación.

Para solucionar problemas con la configuración de comprobaciones de estado en conjuntos de reglas, consulta Reglas de solución de problemas.

Puede considerar las comprobaciones de estado requeridas como "dinámicas" o "estrictas". El tipo de verificación de estado requerida que elijas determina si se requiere que tu rama esté actualizada con la rama base antes de la fusión.

Tipo de verificación de estado requerida	Configuración	Requisitos de fusión	Consideraciones

          **Strict** | La casilla **Requerir que las ramas estén actualizadas antes de la combinación** está activada. | La rama puntual **debe** estar actualizada con la rama base antes de la combinación. | Este es el comportamiento predeterminado para las verificaciones de estado requeridas. Se pueden requerir más compilaciones, ya que deberás actualizar la rama principal después de que otros colaboradores actualicen la rama de destino.|

| Flexible | La casilla Requerir que las ramas estén actualizadas antes de fusionar****no está activada. | La rama no tiene que estar actualizada con la rama base antes de la combinación. | Tendrás menos construcciones requeridas, ya que no necesitarás actualizar la rama de encabezado después de que otros colaboradores fusionen las solicitudes de extracción. Las verificaciones de estado pueden fallar después de que fusiones tu rama si hay cambios incompatibles con la rama de base. | | Deshabilitada | La casilla Requerir que las comprobaciones de estado pasen antes de la fusión****no está marcada. | La rama no tiene restricciones de fusión. | Si las verificaciones de estado requeridas no están habilitadas, los colaboradores pueden fusionar la rama en cualquier momento, independientemente de si está actualizada con la rama de base. Esto aumenta la posibilidad de cambios incompatibles.

Para obtener información sobre solución de problemas de comprobación del estado, consulta Resolución de problemas de verificaciones de estado requeridas.

Bloqueo de inserciones forzadas

Puede impedir que los usuarios envíen cambios a las ramas o etiquetas de destino. Esta regla se encuentra habilitada de forma predeterminada.

Si alguien fuerza los envíos de cambios en una rama o etiqueta, las confirmaciones en las que otros colaboradores basaron su trabajo se podrían quitar del historial de la rama o de la etiqueta. Esto puede ocasionar conflictos de fusión o pull requests corruptos. La inserción forzada también se puede usar para eliminar ramas o apuntar una rama a confirmaciones que no se aprobaron en una solicitud de cambios.

Activar los force pushes no invalidará ninguna otra regla. Por ejemplo, si una rama requiere un historial de confirmaciones lineal, no se pueden forzar las confirmaciones de fusión en esa rama.

No puede habilitar los empujes forzados en una rama si un administrador del sitio ha bloqueado los empujes forzados en todas las ramas del repositorio. Para más información, consulta Implantar políticas de gestión de repositorios en su empresa.

Si un administrador de sitio ha bloqueado solo los empujes forzados a la rama predeterminada, aún puede habilitarlos para cualquier otra rama o etiqueta.

Requerir resultados del code scanning

Si los repositorios están configurados con code scanning, puede usar conjuntos de reglas para evitar que las solicitudes de incorporación de cambios se combinen cuando se cumple una de las condiciones siguientes:

• Una herramienta necesaria encuentra una alerta code scanning con una gravedad definida en el conjunto de reglas.
• El análisis de una herramienta necesaria todavía está en curso.
• No se ha configurado una herramienta necesaria para el repositorio.

Para más información, consulta Establecimiento de la protección contra la fusión de análisis de códigos. Para obtener información más general sobre la code scanning, consulta Acerca del examen de código.

Requiera que los flujos de trabajo pasen antes de fusionar

Los flujos de trabajo del conjunto de reglas se pueden configurar en el nivel de organización o empresa para requerir que se pasen flujos de trabajo antes de fusionar las solicitudes de incorporación de cambios. Para más información, consulta Creación de conjuntos de reglas para repositorios de la organización.

Para más información sobre cómo solucionar problemas comunes de configuración de los ajustes del flujo de trabajo del conjunto de reglas, consulta Reglas de solución de problemas.

Uso de un archivo de flujo de trabajo

Para usar esta regla, primero debes crear un archivo de flujo de trabajo. El archivo de flujo de trabajo debe estar en un repositorio que coincida con la visibilidad de los repositorios en los que deseas ejecutarlo. En concreto, un flujo de trabajo público se puede ejecutar en cualquier repositorio de la organización, un flujo de trabajo interno solo se puede ejecutar en repositorios internos y privados, y un flujo de trabajo privado solo se puede ejecutar en repositorios privados. Para más información, consulta Flujos de trabajo.

Si el archivo de flujo de trabajo está en un repositorio interno o privado y quieres usar el flujo de trabajo en otros repositorios de la organización, deberás permitir el acceso al flujo de trabajo desde fuera del repositorio. Para obtener más información, consulta Permiso de acceso a los componentes en un repositorio privado y Permiso de acceso a los componentes en un repositorio interno.

Al agregar esta regla a un conjunto de reglas en la configuración de su organización, especificará el repositorio de origen y el flujo de trabajo que desea aplicar.

Uso del modo «Evaluar» en flujos de trabajo de conjuntos de reglas

Si un flujo de trabajo del conjunto de reglas se ejecuta en modo «Calcular» y es adecuado, puede establecer el flujo de trabajo del conjunto de reglas en modo «Activo» y fusionar mediante combinación la solicitud de cambios sin desencadenar una nueva ejecución del flujo de trabajo.

Si abre una solicitud de cambios antes de crear el conjunto de reglas en modo «Calcular», puede fusionar mediante combinación la solicitud de incorporación de cambios, ya que no se aplica el conjunto de reglas.

Para obtener más información sobre los estados de obligatoriedad, consulta Creación de conjuntos de reglas de un repositorio.

Desencadenadores de eventos compatibles

Los flujos de trabajo del conjunto de reglas admiten el uso de los eventos pull_request, pull_request_target y merge_group. Como resultado, debe especificar uno o varios de estos eventos en la sección on: del flujo de trabajo para que un conjunto de reglas ejecute el flujo de trabajo.

Los filtros que especifique para los eventos admitidos se omiten (por ejemplo, branches, branches-ignore, paths, types, etc.) El flujo de trabajo únicamente se desencadena y siempre se desencadena según los tipos de actividad predeterminados de los eventos admitidos.

Evento	Tipos de actividad predeterminados
pull_request	opened, synchronize, reopened
pull_request_target	opened, synchronize, reopened
merge_group	checks_requested

Selección de ramas específicas con el flujo de trabajo de su conjunto de reglas

La aplicación de esta regla bloqueará las inserciones directas porque los flujos de trabajo del conjunto de reglas se ejecutan como parte de la experiencia de solicitud de cambios y cola de fusión mediante combinación. Por este motivo, no debe aplicar esta regla a un conjunto de reglas que tenga como destino todas las ramas del repositorio.

Esta regla solo se debe agregar a los conjuntos de reglas que tienen como destino las ramas donde todos los cambios de la rama se realizan mediante solicitudes de cambios.

Opcionalmente, puede seleccionar "No requerir comprobaciones de flujos de trabajo en la creación" si desea permitir la creación de ramificaciones independientemente del resultado de la comprobación de estado.

Restricciones de metadatos

Las organizaciones de un plan de GitHub Enterprise pueden acceder a reglas adicionales para controlar cómo se debe aplicar formato a los metadatos de confirmación. Puede usar cadenas literales o sintaxis de expresión regular para definir un patrón al que deben ajustarse los metadatos de confirmación. Por ejemplo, puede requerir que los mensajes de confirmación contengan un número de incidencia GitHub o que el autor o el confirmador tengan una dirección de correo electrónico que termine en @octoorg.com. También puede controlar el formato de los nuevos nombres de rama y nombres de etiqueta. Para obtener una selección de expresiones regulares útiles para los metadatos de confirmación, consulta Creación de conjuntos de reglas de un repositorio.

Si un colaborador intenta actualizar una rama o etiqueta con un commit que no cumpla con sus requisitos, verá un mensaje de error indicándole qué estaba mal con su commit. Este error puede aparecer tanto en la línea de comandos, cuando el usuario hace un push, como en GitHub.com, cuando el usuario intenta hacer un commit o fusionar un pull request. Las confirmaciones son inmutables en Git: una vez que un colaborador ha creado una confirmación, no puede editar los metadatos de la confirmación, por lo que es posible que deba realizar una fusión mediante cambio de base para reescribir su historial de confirmaciones con nuevas confirmaciones antes de que puedan contribuir correctamente a su trabajo en el repositorio.

Las restricciones de metadatos son útiles para aplicar la coherencia entre las confirmaciones en el historial de una rama. Esto puede ser útil para aplicar el cumplimiento de los procedimientos recomendados, como la especificación de confirmaciones convencionales, o para la integración con herramientas que se basen en metadatos de confirmación. Por ejemplo, es más fácil ejecutar scripts basados en el contenido de un mensaje de confirmación si cada mensaje se ajusta a un formato predecible. Es posible que quieras usar restricciones de metadatos como alternativa para configurar scripts de enlace de recepción previa personalizados. Para obtener más información, consulte [AUTOTITLE] (/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks).

Consideraciones importantes para las restricciones de metadatos

Las restricciones de metadatos bloquean las "actualizaciones de referencia". Si un colaborador inserta trabajo que incluye una confirmación que no cumple los requisitos, la inserción no se rechaza, pero tampoco se actualiza la rama ni la etiqueta de destino. Técnicamente, las confirmaciones todavía entran en el repositorio: las confirmaciones serán "recuperables" (puede navegar hasta ellas en el repositorio), pero no son "accesibles" (no están conectadas al historial de una rama o etiqueta). Si la inserción del colaborador también incluye trabajo en otras ramas o etiquetas, con confirmaciones que cumplen los requisitos de esas ramas o etiquetas, esas referencias se actualizarán correctamente.

Las restricciones de metadatos pueden aumentar la fricción de los usuarios que contribuyen a un repositorio. Por lo general, si impones restricciones de metadatos, debes hacerlo en un conjunto limitado de ramas para evitar afectar al trabajo diario de los colaboradores. Por ejemplo, en lugar de requerir mensajes de confirmación coherentes en cualquier rama puntual en la que un colaborador pueda trabajar, debes requerir mensajes de confirmación coherentes en main solamente y, a continuación, requerir solicitudes de incorporación de cambios en main.

Si utilizas squash merges, se omiten los commits individuales del pull request. En su lugar, las restricciones solo se validan con los metadatos de la confirmación de fusión única resultante. La página del pull request valida esta información antes de que se permita la fusión, lo que garantiza que el commit final sea compatible. En el caso de las restricciones de metadatos que se aplican a los correos electrónicos de confirmación, el patrón también debe incluir noreply@github.com para que las fusiones mediante combinación con "squash" cumplan la restricción.

Al agregar restricciones de metadatos a una rama o etiqueta existente, las reglas se aplican para las nuevas confirmaciones insertadas en la rama o etiqueta a partir de ese momento, pero no se aplican al historial existente de la rama o etiqueta.

Restringir rutas de acceso de archivo

Impedir que las confirmaciones que incluyan cambios en las rutas de acceso de archivo especificadas se inserten en el repositorio. El límite es de 200 entradas y hasta 200 caracteres en cada entrada.

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

Impedir que se inserten en el repositorio las confirmaciones que incluyan rutas de acceso de archivos que excedan un límite de caracteres especificado.

Restringir extensiones de archivo

Impedir que las confirmaciones que incluyan archivos con extensiones de archivo especificadas se inserten en el repositorio. El límite es de 200 entradas y hasta 200 caracteres en cada entrada.

Restringir el tamaño del archivo

Impedir que las confirmaciones que superen un límite de tamaño de archivo especificado se inserten en el repositorio.