Puedes crear conjuntos de reglas para controlar cómo los usuarios pueden interactuar con ramas y etiquetas seleccionadas en un repositorio. Al crear un conjunto de reglas, puedes optar por habilitar o deshabilitar las reglas descritas en las secciones siguientes.
Al crear un conjunto de reglas, puedes permitir que determinados usuarios omitan las reglas del conjunto de reglas. Pueden ser usuarios con determinados permisos, equipos específicos o GitHub Apps. Para obtener más información, vea «Acerca de los conjuntos de reglas».
Para obtener más información sobre cómo crear conjuntos de reglas, consulta "Creación de conjuntos de reglas para repositorios de la organización" y "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, consulte "Acerca de las fusiones de las solicitudes de extracción".
Antes de poder requerir un historial de confirmaciones linear, tu repositorio deberá permitir fusiones combinadas o fusiones de rebase. Para obtener más información, vea «Configurar fusiones de solicitudes de extracción».
Implementaciones correctas obligatorias antes de la combinación
Nota: Esta regla no está disponible para los conjuntos de reglas creados en el nivel de organizació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 obtener más información, vea «Acerca de la verificación de firma de confirmación».
Notas:
- Si habilitaste el modo vigilante en la configuración de la cuenta, que indica que tus 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, consulte "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 puedes subir confirmaciones locales a la rama si estas se firmaron y verificaron. También puede combinar confirmaciones firmadas y comprobadas en la rama mediante una solicitud de incorporación de cambios en GitHub Enterprise Cloud. Pero no puede fusionar mediante combinación con "squash" y combinar una solicitud de incorporación de cambios en la rama en GitHub Enterprise Cloud a menos de que sea el creador de esa solicitud. Puede fusión mediante combinación con "squash" y combinar las solicitudes de incorporación de cambios localmente. Para obtener más información, vea «Revisar solicitudes de extracción localmente».
Para obtener más información sobre los métodos de fusión, consulte "Acerca de los métodos de fusión en GitHub."
Requerir una solicitud de cambios antes de combinar
Puedes requerir que todos los cambios en la rama de destino estén asociados a una solicitud de cambios. La solicitud de cambios no tiene que aprobarse necesariamente, pero debe abrirse.
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 puedes 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 inserta cambios nuevos en la rama de solicitud de cambios o hace clic en Actualizar rama, o bien porque se combina una solicitud de cambios en la rama de destino), la revisión de aprobación se descarta como obsoleta y la solicitud de cambios no se puede combinar hasta que alguien apruebe nuevamente el trabajo. Para obtener información sobre la rama de destino, consulta "Acerca de las solicitudes de incorporación de cambios".
Opcionalmente, puedes 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.
Opcionalmente, puedes requerir una probación de alguien que no sea la última persona para insertar en una rama antes de que se pueda combinar una solicitud 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 cambios complejas que requieren muchas revisiones, exigir la aprobación de alguien que no sea la última persona en realizar la inserción puede ser un equilibrio que evite la necesidad de descartar todas las revisiones obsoletas: con esta opción, las revisiones "obsoletas" no se descartan y la solicitud de cambios 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 te 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, puedes requerir que se resuelvan todos los comentarios de la solicitud de cambios antes de que se pueda fusionar con una rama. Esto garantiza que todos los comentarios se traten o reconozcan antes de fusionar.
Requerir la aprobación de las comprobaciones de estado antes de la fusió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. Para obtener más información, consulta "Configurar ramas protegidas" y "Activar verificaciones de estado requeridas". Para obtener más información, vea «Acerca de las verificaciones de estado».
Puedes 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 "Estados de confirmación" en la documentación de REST API.
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ñades una regla comprobación de estado requerida, puedes 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 podrá hacer la fusión. Si seleccionas "cualquier fuente", aún puedes verificar el autor de cada estado listado en la caja de fusión manualmente.
Nota: Para las comprobaciones de estado de nivel de organización, la aplicación debe instalarse con el permiso statuses:write. Solo se muestran las aplicaciones con este permiso al configurar conjuntos de reglas en el nivel de organización.
Puedes 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 la combinación 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 se superen las comprobaciones de estado antes de la combinación no está activada. | 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 consultar información sobre solución de problemas, vea "Solución de problemas para verificaciones de estado requeridas."
Bloqueo de inserciones forzadas
Puedes 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 solicitudes de cambios corruptas. 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.
Habilitar las inserciones de cambios forzadas no invalidará ninguna otra regla. Por ejemplo, si una rama requiere un historial de confirmaciones linear, no puedes forzar la subida de fusión de confirmaciones en esa rama.
Requerir que los flujos de trabajo se completen antes de combinar
Nots: Esta regla reemplaza los flujos de trabajo necesarios para GitHub Actions. Puede obtener más información sobre este cambio en el blog GitHub.
Puedes requerir que todos los cambios realizados en una rama de destino pasen por los flujos de trabajo especificados antes de que se puedan combinar. Esta regla solo se puede configurar en el nivel de organización.
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 obtener más información, vea «Acerca de los 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 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, seleccionarás el repositorio de origen y el flujo de trabajo que deseas aplicar. El flujo de trabajo se desencadena en los eventos pull_request, pull_request_target o merge_group.
Un flujo de trabajo también puede impedir que alguien cree un repositorio, ya que un flujo de trabajo no se puede ejecutar en un repositorio que se está inicializando. Para solucionar este problema, el conjunto de reglas debe tener “Evaluar” como estado de cumplimiento, o alguien con permisos de omisión debe crear el repositorio y omitir la protección de la rama.
Restricciones de metadatos
Notas:
- Agregar restricciones de metadatos puede afectar a la experiencia de los usuarios que contribuyen al repositorio. Antes de aplicar un conjunto de reglas con restricciones de metadatos, puedes seleccionar el estado de cumplimiento "Evaluar" para el conjunto de reglas para probar los efectos de las restricciones de metadatos sin que ello afecte a los colaboradores. Para más información sobre las restricciones de metadatos, consulta "Reglas disponibles para conjuntos de reglas".
- Las restricciones de metadatos están pensadas para aumentar la coherencia entre confirmaciones en el repositorio. No están diseñadas para reemplazar medidas de seguridad, como requerir la revisión de código mediante solicitudes de cambios.
- Si realizas en una rama una fusión mediante combinación con "squash", todas las confirmaciones de esa rama deben cumplir los requisitos de metadatos de la rama base.
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. Puedes 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, puedes 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 puedes 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 una confirmación que no cumple tus requisitos, el colaborador verá un error que le indicará lo que ha producido un error con su confirmación. Este error puede aparecer en la línea de comandos, cuando el usuario envía cambios, y en GitHub.com, cuando el usuario intenta realizar una confirmación o combinar una solicitud de cambios. 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.
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" (puedes 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 usas fusiones mediante combinación con "squash", debes tener en cuenta que las restricciones de metadatos se evalúan antes de la combinación, por lo que todas las confirmaciones de la solicitud de incorporación de cambios deben cumplir los requisitos. 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.