Esta versión de GitHub Enterprise se discontinuó el 2021-09-23. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Administrar una regla de protección de rama

Puedes crear una regla de protección de rama para requerir ciertos flujos de trabajo en una o más ramas, tal como requerir una revisión de aprobacion o verificaciones de un estado que pase para todas las solicitudes de cambios que se fusionan en la rama protegida.

People with admin permissions to a repository can manage branch protection rules.

Las ramas protegidas están disponibles en los repositorios públicos con GitHub Free y GitHub Free para las organizaciones, y en los repositorios públicos y privados con GitHub Pro, GitHub Team, Nube de GitHub Enterprise, y GitHub Enterprise Server.

Acerca de las reglas de protección de rama

Puedes crear una regla de protección de rama en un repositorio para la rama específica, todas las ramas, o cualquier rama que coincida con un patrón de nombre que especifiques con la sintaxis fnmatch. Por ejemplo, para proteger cualquier rama que contenga la palabra release, puedes crear una regla de rama de *release*.

Puedes crear una regla para todas las ramas actuales y futuras de tu repositorio con la sintaxis de comodín *. Ya que GitHub utiliza el indicador File::FNM_PATHNAME para la sintaxis File.fnmatch el comodín no empata con los separadores de directorio (/). Por ejemplo, qa/* empatará con todas las ramas que comiencen con qa/ y contengan una sola diagonal. Puedes incluir varias diagonales con qa/**/*, y puedes extender la secuencia de qa con qa**/**/* para hacer la regla más inclusiva. Para más información sobre las opciones de sintaxis para las reglas de la rama, consulta la documentación fnmatch.

Si un repositorio tiene varias reglas de rama protegida que afectan las mismas ramas, las reglas que incluyen el nombre de una rama específica tienen la mayor prioridad. Si hay más de una regla de rama protegida que hace referencia al mismo nombre de rama específico, entonces la regla de rama creada primera tendrá la prioridad más alta.

Las reglas de rama protegida que mencionen un caracter especial, como *, ? o ], se aplican en el orden que fueron creadas, así que las reglas más antiguas con estos caracteres tienen la prioridad más alta.

Para crear una excepción a una regla de rama existente, puedes crear una nueva regla de protección de rama que sea una prioridad superior, como una regla de rama para un nombre de rama específico.

Para obtener más información sobre cada uno de los ajustes de protección de rama disponibles, consulta la sección "Acerca de las ramas protegidas".

Crear una regla de protección de rama

Cuando creas una regla de rama, la rama que especifiques no tendrá que en el repositorio aún.

  1. En GitHub Enterprise Server, visita la página principal del repositorio.
  2. Debajo de tu nombre de repositorio, da clic en Configuración. Botón de configuración del repositorio
  3. En el menú izquierdo, da clic en Ramas. Sub-menú de opciones de repositorio
  4. Junto a "Reglas de protección de rama", da clic en Agregar regla. Botón de agregar regla de protección de rama
  5. Debajo del "Patrón del nombre de la rama", teclea el nombre de la rama o el patrón que quieras proteger. Campo de regla de rama
  6. Opcionalmente, habilita las revisiones requeridas para las solicitudes de cambios.
    • Debajo de "Proteger las ramas coincidentes", selecciona Requerir revisiones de solicitudes de cambios antes de fusionar. Casilla de verificación Restricción de revisión de solicitud de extracción
    • Da clic en el menú desplegable de Revisiones de aprobación requeridas y luego selecciona la cantidad de revisiones de aprobación que te gustaría requerir para la rama. Menú desplegable para seleccionar el número de aprobaciones de revisión requeridas
    • Opcionalmente, para descartar una revisión de aprobación de la solicitud de cambios cuando una confirmación que modifica el código se sube a la rama, selecciona Descartar las aprobaciones de solicitudes de cambios estancadas cuando se suban confirmaciones nuevas. Casilla de verificación Descartar aprobaciones de solicitudes de extracción en espera cuando se suben nuevas confirmaciones
    • Opcionalmente, para requerir una revisión de un propietario del código cuando la solicitud de cambios afecte al código que tenga un propietario designado, selecciona Requerir la revisión de los propietarios del código. Para obtener más información, consulta "Acerca de los propietarios del código." Requerir revisión de los propietarios del código
    • Opcionalmente, si el repositorio es parte de una oranización, selecciona Restringir quién puede descartar las revisiones de una solicitud de cambios. Posteriormente, busca y selecciona a las personas o equipos que se les permitirá descartar las revisiones de solicitudes de cambios. Para obtener más información, consulta "Descartar una revisión de solicitud de extracción". Restringir quién puede descartar la casilla de verificación de revisiones de solicitudes de extracción
  7. Opcionalmente, habilita las verificaciones de estado requeridas.
    • Selecciona Requerir verificaciones de estado requeridas antes de la fusión. Opción Verificaciones de estado requeridas
    • Opcionalmente, para garantizar que las solicitudes de cambios se prueban con el último código en la rama protegida, selecciona Requerir que las ramas estén actualizadas antes de fusionarlas. Casilla de verificación de estado estricta o poco estricta
    • Selecciona las verificaciones que quieres requerir de la lista de verificaciones de estado disponibles. Lista de verificaciones de estado disponibles
  8. Opcionalmente, selecciona Requerir confirmaciones firmadas. Opción Requerir confirmaciones firmadas
  9. Opcionalmente, selecciona Requerir un historial linear. Opción para requerir historial linear
  10. También puedes seleccionar Incluir administradores. Casilla de verificación Incluir administradores
  11. Opcionalmente, habilita las restricciones de rama.
    • Selecciona Restringir quién puede subir a las ramas coincidentes. Casilla de verificación para restricción de rama
    • Busca y selecciona las personas, equipos, o apps que tendrán permiso para subir información a la rama protegida. Búsqueda de restricciones de rama
  12. Opcionalmente, debajo de "Reglas que se aplican a todos, incluyendo administradores", selecciona permitir las subidas forzadas. Permitir la opción de subida de información forzada
  13. Opcionalmente, selecciona Permitir los borrados. Opción para habilitar las eliminaciones de ramas
  14. Da clic en Crear.

Editar una regla de protección de rama

  1. En GitHub Enterprise Server, visita la página principal del repositorio.
  2. Debajo de tu nombre de repositorio, da clic en Configuración. Botón de configuración del repositorio
  3. En el menú izquierdo, da clic en Ramas. Sub-menú de opciones de repositorio
  4. A la derecha de la regla de protección de rama que quieras editar, da clic en Editar. Botón editar
  5. Haz los cambios que desees en la regla de protección de rama.
  6. Haz clic en Guardar cambios. Botón Editar mensaje

Borrar una regla de protección de rama

  1. En GitHub Enterprise Server, visita la página principal del repositorio.
  2. Debajo de tu nombre de repositorio, da clic en Configuración. Botón de configuración del repositorio
  3. En el menú izquierdo, da clic en Ramas. Sub-menú de opciones de repositorio
  4. A la derecha de la regla de protección de rama que quieras borrar, da clic en Borrar. Botón de borrar