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 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 y bots 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.

Nota:

Si habilitó el modo vigilante en la configuración de la cuenta, que indica que sus confirmaciones siempre se firmarán, cualquier confirmación que GitHub identifique como "Verificada parcialmente" se permitirá en aquellas ramas que requieran confirmaciones firmadas. Para obtener más información sobre el modo vigilante, consulta Mostrar los estados de verificación para todas tus confirmaciones.
Si un colaborador sube una confirmación sin firmar a una rama que requiere firmas de confirmación, este necesitará rebasar dicha confirmación para incluir una firma verificada y luego subir forzadamente la confirmación reescrita a esta.

Siempre puede subir confirmaciones locales a la rama si estas se firmaron y verificaron. También puede combinar confirmaciones firmadas y verificadas en la rama mediante una solicitud de incorporación de cambios. Pero no puede fusionar mediante combinación con "squash" ni combinar una solicitud de incorporación de cambios en la rama en GitHub a menos que sea el creador de esa solicitud. Puede fusionar mediante combinación con "squash" y combinar las solicitudes de incorporación de cambios localmente. Para más información, consulta Revisar solicitudes de extracción localmente.

Para obtener más información sobre los métodos de fusión, consulta Acerca de los métodos de combinación en GitHub.

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

Nota:

Si seleccionas Descartar aprobaciones de solicitudes de incorporación de cambios obsoletas cuando se insertan nuevas confirmaciones o Requerir aprobación de la inserción revisable más reciente, se producirá un error al crear manualmente la confirmación de combinación para una solicitud de incorporación de cambios e insertarla directamente en una rama protegida, a menos que el contenido de la combinación coincida exactamente con la combinación generada por GitHub para la solicitud de incorporación de cambios.

Además, con esta configuración, las revisiones aprobadas se descartarán por obsoletas si la base de combinación introduce nuevos cambios después de enviar la revisión. La base de combinación es la confirmación que es el último antecesor común entre la rama de tema y la rama base. Si cambia la base de combinación, la solicitud de incorporación de cambios no se puede combinar hasta que alguien apruebe el trabajo de nuevo.

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.

Revisores requeridos

Opcionalmente, puede requerir revisión o aprobación de equipos específicos cuando una solicitud de incorporación de cambios cambia determinados archivos o directorios. Puede especificar hasta 15 equipos diferentes y para cada equipo puede requerir un número determinado de aprobaciones de los miembros del equipo.

La lista desplegable Revisor permite seleccionar cualquier equipo que esté en el ámbito en el que se define la regla.

        **Reglas de toda** la organización: el equipo debe pertenecer a la organización.

        **Reglas de nivel de repositorio**: el equipo debe pertenecer a la organización propietaria del repositorio.

Esta regla no está disponible en repositorios propiedad del usuario, ya que no contienen equipos.

Las aprobaciones necesarias se pueden establecer de 0 (cero) a 10. Requerir cero aprobaciones significa que el equipo se agregará para la visibilidad, pero no necesita aprobar la solicitud.

Para cada equipo, puede especificar una lista de patrones de archivo que determina a qué archivos se aplica la configuración. El formato de esta lista de archivos es el mismo que un archivo estándar .gitignore :

Un patrón que comienza con un signo de exclamación (!) es una negación. Esto hará que las rutas que coincidan con patrones anteriores no requieran aprobación.
Los patrones coinciden en orden, por lo que los patrones negados pueden "no coincidir" con los archivos que coincidan con las reglas anteriores.

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.

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.

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.

Requerir resultados de calidad de código

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

El análisis todavía está en curso.
El análisis falla por cualquier motivo, por ejemplo: ha agotado su presupuesto para minutos de acciones.
Code Quality encontró un resultado de una gravedad correspondiente al nivel definido en el conjunto de reglas o una gravedad mayor.

Para más información, consulta Acerca de la calidad del código de GitHub y Establecimiento de umbrales de calidad de código para solicitudes de incorporación de cambios.

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.