Skip to main content
Publicamos actualizaciones para la documentación con frecuencia y es posible que aún se esté traduciendo esta página. Para obtener la información más reciente, consulta la documentación en inglés.

Acerca de las ramas protegidas

Puedes proteger las ramas importantes si configuras las reglas de protección de rama, las cuales definen si los colaboradores pueden borrar o hacer subidas forzadas a la rama y configura los requisitos para cualquier subida a la rama, tal como que pasen las verificaciones de estado o un historial de confirmaciones linear.

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, GitHub Enterprise Cloud, y GitHub Enterprise Server.

Acerca de las reglas de protección de rama

Puedes requerir ciertos flujos de trabajo o requisitos antes de que un colaborador pueda subir los cambios a una rama en tu repositorio, incluyendo la fusión de una solicitud de cambios en la rama, si creas una regla de protección de rama.

Predeterminadamente, cada regla de protección de rama inhabilita las subidas forzadas en las ramas coincidentes y previene que éstas se borren. Opcionalmente, puedes inhabilitar estas restricciones y habilitar la configuración adicional de protección de ramas.

De forma predeterminada, las restricciones de una regla de protección de rama no se aplican a los usuarios con permisos de administrador para el repositorio o roles personalizados con el permiso "omitir protecciones de rama". Opcionalmente, también puedes aplicar las restricciones a administradores y roles con el permiso "omitir protecciones de rama". Para obtener más información, consulta "Administración de roles de repositorio personalizados para una organización".

Puede crear una regla de protección de rama en un repositorio para una rama específica, todas las ramas o cualquier rama que coincida con un patrón de nombre que especifique con la sintaxis fnmatch. Por ejemplo, para proteger todas las ramas que contengan la palabra release, puede crear una regla de rama para *release*. Para más información sobre los patrones de nombre de rama, vea "Administración de una regla de protección de rama".

Puedes configurar una solicitud de cambios para que se fusione automáticamente cuando se cumplan todos los requisitos de fusión. Para más información, vea "Combinación automática de una solicitud de incorporación de cambios".

Acerca de la configuración de protección de rama

Para cada regla de protección de rama, puedes elegir habilitar o inhabilitar la siguiente configuración.

Para más información sobre cómo configurar la protección de ramas, vea "Administración de una regla de protección de rama".

Requerir revisiones de solicitudes de cambio antes de fusionarlas

Los administradores de repositorio pueden requerir que las solicitudes de cambios reciban una cantidad específica de revisiones de aprobación antes de que alguien fusione la solicitud de extracción en 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 protegida a través de una solicitud de cambios que se encuentre aprobada por el total de revisores requeridos con permisos de escritura.

Si un usuario con permisos administrativos elige la opción Solicitar cambios en una revisión, tendrá que aprobar la solicitud de incorporación 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.

Si un colaborador intenta fusionar una solicitud de cambios con revisiones rechazadas o pendientes en la rama protegida, el colaborador recibirá un mensaje de error.

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Opcionalmente, puedes elegir descartar las aprobaciones de la solicitud de cambios estancada cuando se suban las confirmaciones. Si cualquiera sube una confirmación que modifique el código de una solicitud de cambios aprobada, la aprobación se descartará y la solicitud de cambios no podrá fusionarse. Esto no aplicará si el colaborador sube confirmaciones que no modifiquen el código, como fusionar la rama base en la rama de la solicitud de cambios. Para obtener información sobre la rama base, vea "Acerca de las solicitudes de incorporación de cambios".

Opcionalmente, puedes restringir la capacidad para descartar las revisiones de las solicitudes de cambio para que solo puedan hacerlas algunos equipos o personas específicos. Para más información, vea "Descarte de la revisión de una solicitud 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 afecte dicho código antes de que la solicitud de cambios pueda fusionarse en la rama protegida.

Requerir verificaciones de estado antes de las fusiones

Las verificaciones 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 protegida. Para obtener más información, consulta "Configurar ramas protegidas" y "Activar verificaciones de estado requeridas". Para más información, vea "Acerca de las comprobaciones de estado".

Antes de que puedas habilitar las comprobaciones de estado requeridas, debes configurar el repositorio para utilizar la API de estado de confirmación. Para obtener más información, consulta "Estados de confirmación" en la documentación de la API REST.

Después de habilitar las verificaciones de estado requierdas, cualquier verificación de estado deberá pasar antes de que los colaboradores puedan fusionar los cambios en la rama protegida. Una vez que hayan pasado todas las verificaciones de estado requeridas, cualquier confirmación deberá ya sea subirse en otra rama y después fusionarse, o subirse directo a la rama protegida.

Cualquier usuario o integración con permisos de escritura en un repositorio puede configurar el estado de cualquier comprobación de estado en el repositorio, pero en algunos casos, es posible que solo quieras aceptar una comprobación de estado de una instancia concreta de GitHub App. Cuando agregas una verificación de estado requerida, puedes seleccionar una app que haya configurado su verificación recientemente como la fuente esperada de actualizaciones de estado. Si cualquier otra persona o integración configura el estado, no se permitirá la fusión. Si seleccionas "cualquier fuente", aún puedes verificar el autor de cada estado listado en la caja de fusión manualmente.

Puedes configurar las verificaciones de estado requeridas para que sean "laxas" 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 requeridaConfiguraciónRequisitos de fusiónConsideraciones
StrictLa casilla Requerir que las ramas estén actualizadas antes de la combinación está activada.La rama 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 construcciones, ya que deberás actualizar la rama de encabezado después de que otros colaboradores fusionen las solicitudes de extracción con la rama de base protegida.
FlexibleLa 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.
DeshabilitadaLa 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 obtener información de solución de problemas, vea "Solución de problemas de comprobaciones de estado necesarias".

Requerir la resolución de conversaciones antes de fusionar

Requiere que se resuelvan todos los comentarios de la solicitud de cambios antes de qeu se pueda fusionar con una rama protegida. Esto garantiza que todos los comentarios se traten o reconozcan antes de fusionar.

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, vea "Acerca de la comprobación de firmas de confirmación".

Nota: Si un colaborador inserta una confirmación sin firmar en una rama en la que se exigen firmas de confirmación, tendrá que fusionar mediante cambio de base la confirmación para incluir una firma verificada y, después, forzar la inserción de la confirmación reescrita en la rama.

Siempre puedes subir confirmaciones locales a la rama si estas se firmaron y verificaron. Pero no puede combinar solicitudes de incorporación de cambios en la rama en GitHub Enterprise Server. Puede combinar las solicitudes de incorporación de cambios localmente. Para más información, vea "Extracción del repositorio de solicitudes de incorporación de cambios localmente".

Requerir un historial linear

El requerir un historial de confirmaciones linear previene que los colaboradores suban confirmaciones de fusión a la rama. Esto significa que cualquier solicitud de extracción fusionada con la rama protegida deberá utilizar una fusión combinada o una fusión de rebase. Un historial de confirmaciones estrictamente linear puede ayudar a los equipos a revertir los cambios con mayor facilidad. Para más información sobre los métodos de combinación, vea "Acerca de las combinaciones de solicitudes de incorporación de cambios".

Antes de poder requerir un historial de confirmaciones linear, tu repositorio deberá permitir fusiones combinadas o fusiones de rebase. Para más información, vea "Configuración de combinaciones de solicitud de incorporación de cambios".

Implementaciones correctas obligatorias antes de la combinació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.

No permitir omitir la configuración anterior

De forma predeterminada, las restricciones de una regla de protección de rama no se aplican a los usuarios con permisos de administrador para el repositorio o roles personalizados con el permiso "omitir protecciones de rama" en un repositorio.

También puedes habilitar esta configuración para aplicar las restricciones a administradores y roles con el permiso "omitir protecciones de rama". Para obtener más información, consulta "Administración de roles de repositorio personalizados para una organización".

Restringir quiénes pueden subir a las ramas coincidentes

Cuando habilitas las restricciones de rama, solo los usuarios, equipos o apps a los que se les haya dado permisos pueden subir información a la rama protegida. Puedes ver y editar los usuarios, equipos o apps con acceso de escritura a una rama protegida en la configuración de la misma. Cuando se requieren las comprobaciones de estado, aún se prevendrá que las personas, equipos y aplicaciones que tienen permiso de subida a una rama protegida realicen fusiones mediante combinación en caso de que fallen las comprobaciones requeridas. Las personas, equipos y apps que tengan permiso de subida a una rama protegida aún necesitarán crear solicitudes de cambio cuando estas se requieran.

Opcionalmente, puedes aplicar las mismas restricciones a la creación de ramas que coincidan con la regla. Por ejemplo, si creas una regla que solo permite que un equipo determinado suba información a cualquier rama que contenga la palabra release, solo los miembros de ese equipo podrían crear una nueva rama con la palabra release.

Solo puedes dar acceso de escritura a una rama protegida, o bien conceder permiso para crear una rama coincidente, a usuarios, equipos o GitHub Apps instaladas con acceso de escritura a un repositorio. Las personas y aplicaciones con permisos administrativos en un repositorio siempre pueden subir información a una rama protegida o crear una rama coincidente.

Permitir las subidas forzadas

De manera predeterminada, GitHub Enterprise Server bloquea las inserciones forzadas en todas las ramas protegidas. Cuando habilitas las subidas forzadas a una rama protegida, puedes elegir uno de dos grupos que pueden hacerlas:

  1. Permitir que todos los que por lo menos tengan permisos de escritura en el repositorio suban información forzadamente a la rama, incluyendo aquellos con permisos administrativos.
  2. Permitir que solo personas o equipos específicos suban información forzadamente a la rama.

Si alguien sube información de forma forzada a una rama, esta subida forzada podría sobrescribir confirmaciones en las que otros colaboradores basaron su trabajo. Las personas pueden tener conflictos de fusión o solicitudes de cambios corruptas.

Habilitar las subidas forzadas no invalidará ninguna otra regla de protección a la rama. Por ejemplo, si una rama requiere un historial de confirmaciones linear, no puedes forzar la subida de fusión de confirmaciones en esa rama.

No puede habilitar las inserciones forzadas en una rama protegida si un administrador del sitio las ha bloqueado en todas las ramas del repositorio. Para obtener más información, consulta "Bloqueo de inserciones forzadas en repositorios que pertenecen a una cuenta personal u organización".

Si un administrador de sitio ha bloqueado las subidas de información forzadas en la rama predeterminada únicamente, entonces aún puedes habilitarlas en cualquier otra rama protegida.

Permitir el borrado

Por defecto, no puedes eliminar una rama protegida. Cuando habilitas el borrado de una rama protegida, cualquiera que tenga por lo menos permiso de escritura en el repositorio podrá borrar la rama.