Creación de conjuntos de reglas de un repositorio

Introducción

Puede crear conjuntos de reglas para controlar cómo los usuarios pueden interactuar con ramas y etiquetas seleccionadas en un repositorio. Puedes controlar aspectos como quién puede insertar confirmaciones en una rama determinada y cómo se debe dar formato a las confirmaciones, o quién puede eliminar una etiqueta o cambiarle el nombre. También puedes impedir que los usuarios cambien el nombre de los repositorios.

También puedes crear conjuntos de reglas de inserción para bloquear inserciones en un repositorio privado o interno y toda la red de bifurcación del repositorio. Los conjuntos de reglas de inserción permiten bloquear inserciones basadas en extensiones de archivo, longitudes de ruta de acceso de archivo, rutas de acceso de archivo y carpetas y tamaños de archivo.

Al crear un conjunto de reglas, puede permitir que determinados usuarios omitan las reglas del conjunto de reglas.

Para obtener más información sobre los conjuntos de reglas, consulta Acerca de los conjuntos de reglas.

También puede crear conjuntos de reglas para todos los repositorios de una organización. Para más información, consulta Creación de conjuntos de reglas para repositorios de la organización.

Importación de conjuntos de reglas creados previamente

Para importar uno de los conjuntos de reglas creados previamente por GitHub, vea github/ruleset-recipes.

Puedes importar un conjunto de reglas desde otro repositorio u organización mediante un archivo JSON. Esto puede ser útil si deseas aplicar el mismo conjunto de reglas a varios repositorios u organizaciones. Para obtener más información, consulta Administración de conjuntos de reglas para repositorios de la organización..

Uso de la sintaxis fnmatch

Puedes usar la sintaxis fnmatch para definir patrones de destino al crear un conjunto de reglas.

Puede usar el carácter comodín * para que coincida con cualquier cadena de caracteres. Como GitHub usa la marca File::FNM_PATHNAME para la sintaxis File.fnmatch, el carácter comodín * no coincide con los separadores de directorios (/). Por ejemplo, qa/* coincidirá con todas las ramas que comienzan por qa/ y que contienen una sola barra diagonal, pero no coincidirá con qa/foo/bar. Puedes incluir cualquier número de barras diagonales después de qa con qa/**/*, que coincidiría, por ejemplo, con qa/foo/bar/foobar/hello-world. También puedes extender la cadena qa con qa**/**/* para que la regla sea más inclusiva.

Para más información sobre las opciones de sintaxis, consulta la documentación de fnmatch.

Sintaxis fnmatch no admitida

Nota: No todas las expresiones de la sintaxis fnmatch se admiten en las reglas de protección de ramas. Ten presente las siguientes consideraciones:

• No se puede usar el carácter de barra diagonal inversa (\) como carácter de comillas, ya que GitHub no admite el uso de barras diagonales inversas en las reglas de protección de ramas.
• Puedes especificar juegos de caracteres entre corchetes ([]), pero actualmente no puedes complementar un conjunto con el operador ^ (por ejemplo, [^charset]).
• Aunque GitHub admite File::FNM_PATHNAME en la sintaxis de fnmatch, File::FNM_EXTGLOB no se admite.

Uso de expresiones regulares para metadatos de confirmación

Al agregar restricciones de metadatos a un conjunto de reglas destinado a ramas o etiquetas, puedes usar la sintaxis de expresión regular para definir patrones con los que los metadatos pertinentes, como el mensaje de confirmación o el nombre de la rama o etiqueta, deben o no coincidir.

Las restricciones de metadatos no aceptan patrones regex de forma predeterminada. Para habilitarlo, selecciona Debe coincidir con una restricción de patrón regex determinada al crear las restricciones de metadatos para el conjunto de reglas.

Los conjuntos de reglas admiten la sintaxis RE2. Para más información, consulta la guía de la sintaxis de Google. Para validar las expresiones, puedes usar el validador en regex101.com, seleccionando el tipo "Golang" en la barra lateral izquierda.

De forma predeterminada, en las restricciones de metadatos las expresiones regulares no tienen en cuenta varias líneas de texto. Por ejemplo, si tienes un mensaje de confirmación con varias líneas, el patrón ^ABC será una coincidencia si la primera línea del mensaje comienza por ABC. Para que coincidan varias líneas del mensaje, inicia la expresión con (?m).

No se admite la aserción de búsqueda anticipada (lookahead) negativa, indicada como ?!. Sin embargo, en los casos en los que necesites buscar una cadena determinada que no vaya seguida de otra cadena específica, puedes usar la aserción de búsqueda anticipada (lookahead) positiva, indicada como ?, combinada con el requisito "No debe coincidir con un patrón regex determinado".

Patrones de expresiones regulares útiles

En los ejemplos siguientes se proporcionan patrones útiles para los metadatos de confirmación. Para usar estos patrones, establece Requisito en "Debe coincidir con un patrón regex determinado".

Asegurarse de que los nombres de rama son compatibles con Windows

Puedes usar el siguiente patrón para asegurarte de que los nombres de rama solo incluyen números, letras minúsculas y los caracteres - y _. Esto garantiza que los nombres de rama sean compatibles con sistemas operativos que no usen sistemas de archivos que distinguen mayúsculas de minúsculas de forma predeterminada.

\A[0-9a-z-_]$

\A[0-9a-z-_]$

Coincide con: my-branch.

No coincide con: myBranch.

Asegurarse de que los nombres de etiqueta usan el versionamiento semántico

Puedes usar el siguiente patrón para asegurarte de que los nombres de etiqueta se ajustan al versionamiento semántico. Para obtener más información, consulta la documentación sobre semver.org.

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Coincide con: 1.2.3, 10.20.30 y 1.1.2-prerelease+meta.

No coincide con: 1.2 y 1.2-SNAPSHOT.

Limitar la longitud de las líneas en los mensajes de confirmación

El libro Pro Git recomienda limitar la primera línea de un mensaje de confirmación a unos 50 caracteres.

Puedes usar el siguiente patrón para asegurarte de que la primera línea de un mensaje de confirmación contiene 50 caracteres o menos.

\A.{1,50}$

\A.{1,50}$

Asegurarse de que los mensajes de confirmación comienzan con una resolución y un número de incidencia

Puedes usar el siguiente patrón para asegurarte de que los mensajes de confirmación contienen la palabra Resolves: o Fixes:, seguida de una cadena como #1234.

^(Resolves|Fixes): \#[0-9]+$

^(Resolves|Fixes): \#[0-9]+$

Coincide con: Fixes: #1234.

No coincide con: Add conditional logic to foo.bar.

Aplicación de confirmaciones convencionales

Puedes usar el siguiente patrón para asegurarte de que los mensajes de confirmación se ajustan a la especificación de confirmaciones convencionales. Para obtener más información, consulta conventionalcommits.org.

^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

Coincide con: feat: allow provided config object to extend other configs.

No coincide con: Add conditional logic to foo.bar.

Uso de los estados de cumplimiento del conjunto de reglas

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 obtener más información, vea «Administración de conjuntos de reglas de un repositorio».

Creación de un conjunto de reglas de rama o etiqueta

1. En GitHub, navegue hasta la página principal del repositorio.

2. En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.

   

3. En la barra lateral izquierda, en "Código y automatización", haz clic en Reglas y, a continuación, haz clic en Conjuntos de reglas.

   

4. Haga clic en Nuevo conjunto de reglas.

5. Para crear un conjunto de reglas que tenga como destino ramas, haz clic en Nuevo conjunto de reglas de rama.

6. Como alternativa, para crear etiquetas de destino de un conjunto de reglas, haz clic en Nuevo conjunto de reglas de etiquetas.

7. En «Nombre del conjunto de reglas», escribe un nombre para el conjunto de reglas.

8. Opcionalmente, para cambiar el estado de cumplimiento predeterminado, haz clic en Deshabilitado y selecciona un estado de cumplimiento. Para obtener más información sobre los estados de obligatoriedad, consulte «Acerca de los conjuntos de reglas».

Concesión de permisos de derivación para tu rama o el conjunto de reglas

Puede conceder determinados roles, equipos o aplicaciones que permisos de omisión , así como la capacidad de aprobar solicitudes de omisión para el conjunto de reglas. Los siguientes son aptos para omitir el acceso:

• Administradores de repositorios, propietarios de organizaciones y propietarios de empresas
• Rol de mantenimiento o escritura, o roles de repositorio personalizados basados en el rol de escritura
• Teams
• GitHub Apps
• Dependabot. Para obtener más información sobre Dependabot, consulta "Guía de inicio rápido de Dependabot".

1. Para conceder permisos de omisión para el conjunto de reglas, en la sección "Lista de omisión", haga clic en Agregar omisión.

2. En el cuadro de diálogo modal "Agregar omisión" que aparece, busque el rol, el equipo o la aplicación que desea conceder permisos de omisión y, a continuación, seleccione el rol, el equipo o la aplicación en la sección "Sugerencias" y haga clic en Agregar seleccionado.

3. Opcionalmente, para conceder omisión a un actor sin permitirles insertar directamente en un repositorio, a la derecha de «Permitir siempre», haz clic en y, a continuación, haz clic en Solo para solicitudes de incorporación de cambios.

   El actor seleccionado debe ahora abrir una solicitud de incorporación de cambios para realizar cambios en un repositorio, creando una pista digital clara en la solicitud de cambios y el registro de auditoría. Luego, el actor puede optar por omitir las protecciones de rama y combinar esa solicitud de incorporación de cambios.

Elección de las ramas o etiquetas de destino

Para definir ramas o etiquetas, en la sección "Ramas objetivo" o "Etiquetas objetivo", seleccione Agregar un objetivo y, a continuación, seleccione cómo desea incluir o excluir ramas o etiquetas. Puedes usar la sintaxis fnmatch para incluir o excluir ramas o etiquetas en función de un patrón. Para más información, consulta "Uso de la sintaxis fnmatch".

Puedes agregar varios criterios de selección de destino al mismo conjunto de reglas. Por ejemplo, podrías incluir la rama predeterminada, incluir cualquier rama que coincida con el patrón *feature* y, a continuación, excluir específicamente una rama que coincida con el patrón not-a-feature.

Selección de protecciones de rama o etiqueta

En la sección "Protecciones de ramas" o "Protecciones de etiquetas", selecciona las reglas que deseas incluir en el conjunto de reglas. Al seleccionar una regla, es posible que puedas especificar una configuración adicional para la regla. Para obtener más información sobre las reglas, consulta "Reglas disponibles para conjuntos de reglas".

Adición de restricciones de metadatos

Las restricciones de metadatos deben estar 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.

1. Para agregar una regla para controlar los metadatos del commit o los nombres de rama, en la sección "Restrictions", haz clic en Restrict commit metadata o Restrict branch names.

2. Configura los ajustes de la restricción y, a continuación, haz clic en Añadir. Puedes agregar varias restricciones al mismo conjunto de reglas.

3. Para que coincida con un patrón regex determinado, en la lista desplegable «Requisito», selecciona Debe coincidir con un patrón regex determinado.

   Para la mayoría de los requisitos, como "Debe empezar con un patrón coincidente", el patrón que escribas se interpreta literalmente y no se admiten caracteres comodín. Por ejemplo, el carácter * solo representa el carácter literal *.

   Para patrones más complejos, puedes seleccionar "Debe coincidir con un patrón regex determinado" o "No debe coincidir con un patrón regex determinado", y luego usar la sintaxis de expresión regular para definir el patrón coincidente. Para obtener más información, consulta «Acerca de las expresiones regulares para los metadatos de confirmación."

   Cualquier persona que vea los conjuntos de reglas de un repositorio podrá ver la descripción que proporciones.

4. Opcionalmente, antes de aplicar un conjunto de reglas con restricciones de metadatos, selecciona el estado de cumplimiento "Evaluate" 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".

Finalización del conjunto de reglas de tu rama o etiqueta y pasos siguientes

Para terminar de crear el conjunto de reglas, haga clic en Crear. Si el estado de cumplimiento del conjunto de reglas se establece en "Activo", el conjunto de reglas entra en vigor inmediatamente.

Puede ver información sobre el conjunto de reglas para ver cómo afectan las reglas a los colaboradores. Si el estado de cumplimiento se establece en "Evaluar", puede ver qué acciones habrían pasado o fallado si el conjunto de reglas estaba activo. Para más información sobre conclusiones para conjuntos de reglas, consulte "Administración de conjuntos de reglas de un repositorio".

Creación de un conjunto de reglas de inserción

Puedes crear un conjunto de reglas de inserción para repositorios privados o internos.

1. En GitHub, navegue hasta la página principal del repositorio.

2. En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.

   

3. En la barra lateral izquierda, en "Código y automatización", haz clic en Reglas y, a continuación, haz clic en Conjuntos de reglas.

   

4. Haga clic en Nuevo conjunto de reglas.

5. Para crear un conjunto de reglas que tenga como destino ramas, haz clic en Nuevo conjunto de reglas de inserción.

6. En «Nombre del conjunto de reglas», escribe un nombre para el conjunto de reglas.

7. Opcionalmente, para cambiar el estado de cumplimiento predeterminado, haz clic en Deshabilitado y selecciona un estado de cumplimiento. Para obtener más información sobre los estados de obligatoriedad, consulte «Acerca de los conjuntos de reglas».

Concesión de permisos de omisión para el conjunto de reglas de inserción

Puede conceder determinados roles, equipos o aplicaciones que permisos de omisión , así como la capacidad de aprobar solicitudes de omisión para el conjunto de reglas. Los siguientes son aptos para omitir el acceso:

• Administradores de repositorios, propietarios de organizaciones y propietarios de empresas
• Rol de mantenimiento o escritura, o roles de repositorio personalizados basados en el rol de escritura
• Teams
• GitHub Apps
• Dependabot. Para obtener más información sobre Dependabot, consulta "Guía de inicio rápido de Dependabot".

1. Para conceder permisos de omisión para el conjunto de reglas, en la sección "Lista de omisión", haga clic en Agregar omisión.
2. En el cuadro de diálogo modal "Agregar omisión" que aparece, busque el rol, el equipo o la aplicación que desea conceder permisos de omisión y, a continuación, seleccione el rol, el equipo o la aplicación en la sección "Sugerencias" y haga clic en Agregar seleccionado.

Selección de protecciones de inserción

Puedes bloquear inserciones en este repositorio y toda la red de bifurcación de este 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 protecciones de inserción que configures bloquearán las inserciones en este repositorio y en toda la red de bifurcación de este repositorio.

1. En «Protección de inserción», haz clic en las restricciones que deseas aplicar. A continuación, rellena los detalles de las restricciones que selecciones.

   En el caso de las restricciones de ruta de acceso de archivo, puedes usar rutas de acceso parciales o completas. 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 obtener más información, vea «Creación de conjuntos de reglas de un repositorio».

Finalización del conjunto de reglas de inserción y pasos siguientes

Para terminar de crear el conjunto de reglas, haga clic en Crear. Si el estado de cumplimiento del conjunto de reglas se establece en "Activo", el conjunto de reglas entra en vigor inmediatamente.

Puede ver información sobre el conjunto de reglas para ver cómo afectan las reglas a los colaboradores. Si el estado de cumplimiento se establece en "Evaluar", puede ver qué acciones habrían pasado o fallado si el conjunto de reglas estaba activo. Para más información sobre conclusiones para conjuntos de reglas, consulte "Administración de conjuntos de reglas de un repositorio".