Cambiar la rama predeterminada

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

La rama predeterminada es la primera rama que Git restaurará en un clon nuevo. Además, las solicitudes de incorporación de cambios se dirigen a esta rama de forma predeterminada.

Examinaremos el proceso para cambiar la rama predeterminada. También trataremos otros aspectos que debe tener en cuenta y actualizar al realizar este cambio. Por último, veremos una herramienta para facilitar la transición.

Establecimiento de una nueva rama predeterminada

Puede usar una rama distinta de main para los nuevos cambios o cambiar la línea principal de desarrollo en el repositorio. Para cambiar el nombre de la rama predeterminada de los nuevos repositorios, consulte Toda la configuración y las directivas de repositorios.

Para cambiar la rama predeterminada del repositorio para combinar nuevas solicitudes de incorporación de cambios, necesita al menos dos ramas. Si solo hay una rama, ya es la rama predeterminada. Debe crear una segunda rama para cambiar la rama predeterminada.

Nota:

Para cambiar la rama predeterminada, debe tener habilitado el permiso Editar directivas. Para obtener más información, consulte Establecimiento de permisos de repositorios Git.

1. En el repositorio del proyecto, seleccione Ramas.

2. En la página Ramas, seleccione Más opciones junto a la nueva rama predeterminada que quiera y elija Establecer como rama predeterminada.

   

3. Después de establecer la nueva rama predeterminada, puede eliminar la rama predeterminada anterior si quiere.

Hay otros aspectos que debe tener en cuenta antes de realizar este cambio.

Elija un nombre

Git 2.28 agregó la capacidad de elegir un nombre de rama inicial. Al mismo tiempo, Azure Repos, GitHub y otros proveedores de hospedaje de Git agregaron la capacidad de elegir un nombre de rama inicial diferente. Anteriormente, la rama predeterminada casi siempre se llamaba master. El nombre alternativo más popular es main. Entre las opciones menos comunes se incluyen trunk y development. Si no hay restricciones de las herramientas que use o el equipo en el que esté, cualquier nombre de rama válido funcionará.

Actualización de otros sistemas

Al cambiar a otra rama predeterminada, es posible que otras partes del flujo de trabajo se vean afectadas. Tendrá que tener en cuenta estas partes cuando planee un cambio.

Pipelines

Actualice los desencadenadores de CI para todas las canalizaciones. Las canalizaciones del diseñador se pueden editar en la web. Las canalizaciones YAML se pueden editar en sus respectivos repositorios.

Solicitudes de incorporación de cambios en curso

Establezca el destino de cada solicitud de incorporación de cambios abierta a la nueva rama predeterminada.

Clones existentes

Los nuevos clones del repositorio obtendrán la nueva rama predeterminada. Después de la modificación, todos los usuarios con un clon existente deben ejecutar git remote set-head origin -a (reemplazando origin por el nombre de su repositorio remoto si es otra cosa) para actualizar su vista de la rama predeterminada del repositorio remoto. Las nuevas ramas futuras deben basarse en el nuevo valor predeterminado.

Vínculos entrantes

Algunos marcadores, documentos y otros archivos que no son de código que apuntan a archivos en Azure Repos deberán actualizarse. El nombre de la rama de un archivo o directorio puede aparecer en la dirección URL.

Si una dirección URL contiene una cadena de consulta para version, por ejemplo &version=GBmybranchname, esa dirección URL debe actualizarse. Afortunadamente, la mayoría de los vínculos a la rama predeterminada no tendrán un segmento version y se pueden dejar tal cual. Además, una vez que elimine la rama predeterminada anterior, los intentos de navegar a ella se dirigirán a la nueva rama predeterminada de todos modos.

Creación de reflejo temporal

Un repositorio de Git solo puede tener una rama predeterminada. Sin embargo, durante un tiempo, puede configurar la creación de un reflejo ad hoc entre la rama predeterminada anterior y la nueva rama predeterminada. De este modo, si los usuarios finales siguen enviando cambios a la rama predeterminada anterior, no tendrán que rehacer su trabajo. Usaremos Azure Pipelines para configurar esta creación de reflejo temporal.

Nota:

En esta sección se usa un lenguaje contrario a la perspectiva de Microsoft. En concreto, la palabra master aparece en varios lugares de forma coherente con la forma en que se usa en Git. El propósito de este tema es explicar cómo cambiar a un lenguaje más inclusivo, como main. Evitar todas las menciones de master haría que las indicaciones fueran mucho más difíciles de entender.

Canalización de creación de reflejo

Nota:

Estas instrucciones no son a prueba de errores y la configuración de su repositorio puede requerir cambios adicionales, como suavizar los permisos y las directivas.

Advertencia

Si las ramas predeterminadas antiguas y nuevas se actualizan antes de que se ejecute esta canalización, la canalización no podrá reflejar los cambios. Alguien tendrá que combinar manualmente la rama predeterminada antigua en la nueva rama predeterminada para volver a ejecutarla automáticamente.

1. Para todas las compilaciones de CI existentes, actualícelas para que se desencadenen en la nueva rama predeterminada en lugar de la antigua.

2. Conceda permiso de Contribución a la identidad de compilación al repositorio. Vaya a Configuración del proyecto>Repositorios>(su repositorio)>Permisos. Puede haber hasta dos identidades, una para el servicio de compilación de colecciones de proyectos y la otra para el servicio de compilación del proyecto. Asegúrese de que el permiso de Contribución dice Permitir.

3. Si la nueva rama predeterminada tiene directivas de rama, conceda también a la identidad de compilación el permiso de Omitir las directivas al insertar. Este permiso es un riesgo de seguridad, ya que un usuario malintencionado podría diseñar una canalización para insertar código en un repositorio del proyecto. Cuando la creación de reflejo ya no sea necesaria, asegúrese de quitar este permiso.

4. Agregue un nuevo archivo mirror.yml al repositorio en la nueva rama predeterminada. En este ejemplo, se supone que la rama predeterminada antigua era master y la nueva es main. Actualice las ramas de desencadenamiento y la línea git push si los nombres de rama son diferentes.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. Cree una canalización y elija "Git de Azure Repos" y "Archivo YAML de Azure Pipelines existente" en el asistente. Elija el archivo mirror.yml que agregó en el paso anterior. Guarde y ejecute la canalización.

Solución de problemas

Esta canalización se ejecutará cada vez que haya una inserción en master o en main. Las mantendrá sincronizadas siempre y cuando las confirmaciones nuevas no lleguen a ambas ramas simultáneamente.

Si la canalización comienza a producir un error con un mensaje de error como "se rechazaron las Actualizaciones porque un extremo de la rama insertada está detrás de su rama remota", alguien tendrá que combinar la rama antigua en la nueva rama a mano.

1. Clone el repositorio y cd en su directorio.
2. Restaure la nueva rama predeterminada con git checkout main (si main es la nueva rama predeterminada).
3. Cree una rama para integrar las dos ramas con git checkout -b integrate.
4. Combine la rama predeterminada anterior con git merge master (si master es la rama predeterminada anterior).
5. Inserte la nueva rama y, a continuación, abra y complete una solicitud de incorporación de cambios en la nueva rama predeterminada.
6. A continuación, la canalización de creación de reflejo debe encargarse de reflejar la confirmación de combinación con la rama predeterminada anterior.