Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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
Prerrequisitos
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Miembro de un proyecto . |
| Permisos | - Ver código en proyectos privados: al menos acceso básico. - Clonar o contribuir al código en proyectos privados: Miembro de la Colaboradores grupo de seguridad o los permisos correspondientes en el proyecto. - Establecer permisos de rama o repositorio: Administrar los permisos relacionados con la rama o el repositorio. - Cambiar la rama predeterminada: Editar directivas para los permisos del repositorio. - Importar un repositorio: miembro del grupo de seguridad de Administradores de proyecto o repositorio Git a nivel de proyecto Crear repositorio con la opción Permitir. Para obtener más información, consulte Establecimiento de permisos de repositorios Git. |
| Servicios | Repositorio habilitado. |
| Herramientas | Opcional. Utilice comandos az repos: CLI de Azure DevOps. |
Nota:
En proyectos públicos, los usuarios con acceso Stakeholders disponen de acceso total a Azure Repos, incluyendo visualización, clonación y contribución al código.
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Miembro de un proyecto . |
| Permisos | - Ver código: al menos acceso básico. - Clonar o contribuir al código: Miembro de la Colaboradores grupo de seguridad o los permisos correspondientes en el proyecto. |
| Servicios | Repositorio habilitado. |
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 funciones y políticas de ramas 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 de tu proyecto deberían tener derechos de compromiso directo en tu repositorio original. 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 forks en un repositorio de GitHub, consulte Administración de la política de fork 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.
- 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
Creación de una bifurcación
En los pasos siguientes se describe cómo bifurcar un repositorio de Git de Azure Repos.
Nota:
Para clonar 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 el fork contendrá todas las ramas o solo la rama predeterminada. Si el repositorio contiene varias ramas temáticas, considere incluir solo la rama predeterminada en su 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, añade un nuevo remoto llamado
upstreame introduce la URL de clonación de Git del repositorio que bifurcaste. Después, elija Guardar.
Inserción de cambios locales en la bifurcación
Al hacer un fork, creas una versión personal del repositorio original (denominado "upstream"). 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 empujar los cambios, consulte Compartir código con push.
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 usuario válido del proyecto y con el permiso Lectura en el repositorio de origen 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ás preparado/a para continuar:
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.