Horquillas
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Las bifurcaciones de repositorio de Git son útiles cuando los usuarios quieren realizar cambios experimentales, arriesgados u ocultos en un código base, pero esos cambios deben aislarse del código base en el repositorio original. Una nueva bifurcación es básicamente un nuevo repositorio remoto que comparte el código fuente del repositorio original.
Como versión independiente, los cambios realizados en la bifurcación, como agregar confirmaciones o ramas, quedan ocultos del repositorio original. Si quiere combinar los cambios de código base en el repositorio original, debe crear una solicitud de incorporación de cambios (PR) para solicitar revisión y aprobación de esos cambios.
El proceso de bifurcación no transfiere ningún permiso, directivas ni canalizaciones de compilación desde el repositorio original a la bifurcación.
En este artículo se explica cómo trabajar con bifurcaciones en Azure Repos repositorios de Git y se proporcionan vínculos al contenido de GitHub que describe cómo administrar bifurcaciones en repositorios de GitHub.
En este artículo, aprenderá a:
- Compartir código entre bifurcaciones
- Elegir entre ramas y bifurcaciones
- Habilitación de bifurcaciones de repositorio
- Creación de una bifurcación
- Clonación de la bifurcación localmente
- Inserción de cambios locales en la bifurcación
- Creación y ejecución de una PR
- Sincronización de la bifurcación
Requisitos previos para el acceso a Azure Repos
Repos debe estar habilitado en la configuración del proyecto de Azure DevOps. Si el centro de Repos y las páginas asociadas no se muestran, vea Activación o desactivación de un servicio de Azure DevOps para volver a habilitar Repos.
Para ver el código en proyectos privados, debe ser miembro de un proyecto de Azure DevOps con el nivel de acceso Básico o superior. En el caso de los proyectos públicos, cualquiera puede ver el código.
Si no tiene un proyecto, cree uno o regístrese de forma gratuita.
Si no es miembro del proyecto, agréguese.
Para clonar o contribuir al código de un proyecto privado, debe ser miembro del grupo de seguridad Colaboradores o tener el conjunto de permisos correspondientes. En el caso de los proyectos públicos, cualquiera puede clonar y contribuir código. Para obtener más información, consulte ¿Qué es un proyecto público?
Nota:
En el caso de los proyectos públicos, los usuarios con acceso de parte interesada tienen acceso total a Azure Repos.
Repos debe estar habilitado en la configuración del proyecto de Azure DevOps. Si el centro de Repos y las páginas asociadas no se muestran, vea Activación o desactivación de un servicio de Azure DevOps para volver a habilitar Repos.
Para ver el código, debe ser miembro del proyecto de Azure DevOps con acceso Básico o superior. Si no es miembro del proyecto, agréguese.
Para clonar o contribuir al código, debe ser miembro del grupo de seguridad Colaboradores, o bien tener el conjunto de permisos correspondientes, en el proyecto que quiera cambiar.
Compartir código entre bifurcaciones
El repositorio original se conoce a menudo como repositorio ascendente. Puede crear solicitudes de incorporación de cambios para combinar cambios en cualquier dirección: de bifurcación a ascendente o de ascendente a bifurcación. La dirección más común es de bifurcación a ascendente. Los permisos, las directivas, las compilaciones y los elementos de trabajo del repositorio de destino se aplicarán a la PR.
Elegir entre ramas y bifurcaciones
Para un equipo pequeño de 2 a 5 desarrolladores, es posible que un flujo de trabajo de bifurcación no sea necesario porque todos pueden trabajar en ramas de características y directivas de rama pueden proteger la rama predeterminada. Sin embargo, si el equipo se expande y supera esta disposición, puede cambiar a un flujo de trabajo de bifurcación.
Si el repositorio tiene un gran número de confirmadores ocasionales o poco frecuentes, como un proyecto de código abierto, se recomienda el flujo de trabajo de bifurcación. Normalmente, solo los colaboradores principales del proyecto tienen derechos de confirmación directa en el repositorio. Otros colaboradores deben usar un flujo de trabajo de bifurcación para aislar sus cambios propuestos hasta que los colaboradores principales tengan la oportunidad de revisar su trabajo.
Habilitación de bifurcaciones de repositorio
Para habilitar bifurcaciones para un repositorio de Git de Azure Repos, consulte Habilitar bifurcaciones.
Para habilitar bifurcaciones para un repositorio de GitHub, consulte Administración de la directiva de bifurcación para su organización.
Flujo de trabajo de bifurcación
El flujo de trabajo de bifurcación consta de cinco pasos que se describen en las secciones siguientes.
- Crear una bifurcación
- Clonación de la bifurcación localmente
- Inserción de cambios locales en la bifurcación
- Creación y ejecución de una PR
- Sincronización de la bifurcación
Creación de una bifurcación
En los pasos siguientes se describe cómo bifurcar un repositorio de Git de Azure Repos.
Nota:
Para bifurcar un repositorio en un proyecto de Azure DevOps, debe tener el permiso Crear repositorio para ese proyecto. Los propietarios del repositorio deben considerar la posibilidad de crear bifurcaciones de un proyecto dedicado y asignar el permiso Crear repositorio a todos los colaboradores. Para obtener más información sobre cómo establecer permisos, consulte Establecimiento de permisos de repositorio de Git.
En el explorador web, vaya al repositorio de Git de Azure Repos que quiera bifurcar. Seleccione Repositorio > Archivos y, después, seleccione Bifurcar en el menú de elipsis para abrir el cuadro de diálogo Bifurcar.
En el cuadro de diálogo Bifurcación, asigne el nombre al repositorio bifurcado, elija el proyecto en el que quiera crear la bifurcación, seleccione las ramas que quiere incluir en la bifurcación y, después, elija Bifurcar. Puede especificar si la bifurcación contendrá todas las ramas o solo la rama predeterminada. Si el repositorio contiene varias ramas puntuales, considere la posibilidad de incluir solo la rama predeterminada en la bifurcación.
Para obtener información sobre cómo bifurcar un repositorio de GitHub, consulte Bifurcación de un repositorio.
Clonación de la bifurcación localmente
Después de bifurcar un repositorio, clone la bifurcación para crear una copia local en una carpeta del equipo. Puede clonar desde la línea de comandos o mediante un IDE como Visual Studio. Para obtener más información sobre cómo clonar un repositorio, consulte Clonación de un repositorio de Git existente.
Al clonar un repositorio remoto, Git asigna el alias origin como abreviatura para la dirección URL del repositorio remoto que ha clonado. Para mayor comodidad, agregue otro alias denominado upstream para el repositorio desde el que realice la bifurcación, lo que se conoce como repositorio ascendente. En los pasos siguientes se describe cómo agregar un alias upstream.
Sugerencia
Para mayor comodidad, puede usar los alias origin y upstream en lugar de sus URL correspondientes en los comandos de Git.
Para agregar un alias upstream en Visual Studio, siga estos pasos:
Elija Herramientas > Opciones en la barra de menús para abrir la ventana Opciones. Seleccione Control de código fuente > Configuración de repositorios de Git > Remotos y, después, elija Agregar para abrir el cuadro de diálogo Agregar remoto.
En el cuadro de diálogo Agregar remoto, agregue un nuevo remoto llamado
upstreamy escriba la dirección URL de clonación de Git del repositorio bifurcado. Después, elija Guardar.
Inserción de cambios locales en la bifurcación
Al bifurcar, se crea una versión personal del repositorio original (el repositorio original se conoce como "ascendente"). La bifurcación es independiente del repositorio ascendente, pero la bifurcación comparte el código y conserva un vínculo al repositorio ascendente, lo que permite una sincronización futura. Por lo tanto, no hay nada para evitar que trabaje directamente en la rama main del clon local y, después, insertar ese trabajo en la rama main de la bifurcación. Sin embargo, generalmente es mejor usar ramas de características para el trabajo. Mediante el uso de ramas de características:
Puede mantener varias secuencias de trabajo independientes simultáneamente.
Es más fácil que otros usuarios comprendan el trabajo que comparte porque ese trabajo se organiza en distintas secuencias de trabajo por rama.
Un flujo de trabajo de Git típico incluye estos pasos:
Crear una característica local o una rama de corrección de errores.
Realice cambios en la nueva rama y confirme su trabajo. Normalmente, las personas realizan varias confirmaciones al trabajar en una característica o corrección de errores.
Insertar la rama de corrección de errores o característica en la bifurcación. La bifurcación tiene el alias
origin.
Para obtener información sobre cómo insertar los cambios, consulte Uso compartido de código con inserción.
Creación y ejecución de una PR
En Azure Repos, para combinar en el repositorio original los cambios que insertó en la bifurcación, puede hacer lo siguiente:
Cree una solicitud de incorporación de cambios para solicitar la revisión y aprobación de los cambios. Al abrir una solicitud de incorporación de cambios, establezca la rama de origen de solicitud de incorporación de cambios en la rama de característica o de corrección de errores en la bifurcación. La rama de destino de solicitud de incorporación de cambios suele ser la rama
maindel repositorio que ha bifurcado. Ese repositorio se conoce como repositorio ascendente y tiene el aliasupstream.En la captura de pantalla siguiente se muestra el repositorio de origen y la rama y el repositorio de destino de una solicitud de incorporación de cambios creada en Azure Repos.
Para más información sobre cómo crear una solicitud de incorporación de cambios mediante el explorador, Visual Studio o la CLI de Azure DevOps, consulte Creación de una solicitud de incorporación de cambios.
Importante
Cualquier persona con el permiso Lectura en el repositorio ascendente puede abrir una solicitud de incorporación de cambios. Si el repositorio ascendente tiene una canalización de compilación de solicitud de incorporación de cambios que está configurada para ejecutarse en la creación de solicitudes de incorporación de cambios, se ejecutará una compilación en los cambios introducidos por la solicitud de incorporación de cambios.
Para que la solicitud de incorporación de cambios se complete, todos los revisores necesarios deben aprobar los cambios de solicitud de incorporación de cambios y se deben cumplir todas las directivas de rama de destino. En la aprobación y finalización de la solicitud de incorporación de cambios, los cambios en la rama de origen de la solicitud de incorporación de cambios se combinarán en la rama de destino de la solicitud de incorporación de cambios.
Para obtener información sobre cómo crear y completar una solicitud de incorporación de cambios de GitHub, consulte Creación de una solicitud de incorporación de cambios y Combinación de una solicitud de incorporación de cambios.
Sincronización de la bifurcación
Una vez que una solicitud de incorporación de cambios combina los cambios de la bifurcación en la rama de destino del repositorio ascendente, puede extraer de la rama de destino del repositorio ascendente para actualizar la rama local correspondiente con los cambios y los cambios realizados por otros colaboradores. Ya está listo para:
Crear una nueva característica o rama de corrección de errores desde la rama local actualizada.
Actualizar la bifurcación insertando desde la rama local actualizada en
origin.
Normalmente, la rama de destino del repositorio ascendente es main. Si no está editando directamente la rama local main (trabaja en ramas de características), la extracción de la rama ascendente actualizará la rama upstream/main local main sin conflictos de combinación.