Cambiar la rama predeterminada

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

La rama predeterminada es la primera rama que Git comprobará en un clon nuevo. Además, las solicitudes de incorporación de cambios tienen como destino esta rama de forma predeterminada.

Le guiaremos por el proceso de cambiar la rama predeterminada. También trataremos otras cosas que debe tener en cuenta y actualizar al realizar este cambio. Por último, veremos una herramienta para facilitar la transición.

Prerrequisitos

Establecimiento de una nueva rama predeterminada

Puede usar una rama distinta main de para los nuevos cambios o cambiar la línea principal de desarrollo en el repositorio. Para cambiar el nombre de rama predeterminado para los nuevos repositorios, consulte Configuración y directivas de todos los 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 predeterminada. Debe crear una segunda rama para cambiar el valor predeterminado.

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

Elegir 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 denominaba 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 del equipo en las que esté, cualquier nombre de rama válido funcionará.

Actualización de otros sistemas

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

Tuberías

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

Vuelva a establecer 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 del modificador, todos los usuarios con un clon existente deben ejecutarse git remote set-head origin -a (reemplazando origin por el nombre de su remoto si es algo más) para actualizar su vista de la rama predeterminada del 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 de Azure Repos deberán actualizarse. El nombre de 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 version segmento y se pueden dejar as-is. Además, una vez que elimine la rama predeterminada anterior, los intentos de navegar a ella se tomarán al nuevo valor predeterminado 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 reflejo ad hoc entre el valor predeterminado anterior y el nuevo valor predeterminado. De este modo, si los usuarios finales continúan insertando en el valor predeterminado anterior, no tendrán que rehacer el trabajo en su final. Usaremos Azure Pipelines para configurar esta creación de reflejo temporal.

Canalización de creación de reflejo

1. Para todas las compilaciones de CI existentes, actualícelas para desencadenarlas en la nueva rama predeterminada en lugar de la anterior.

2. Conceda permiso de contribución a la identidad de compilación al repositorio. Vaya aRepositorios>de configuración del> proyecto (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 Contribuir indica Permitir.

3. Si la nueva rama predeterminada tiene directivas de rama, conceda también la identidad de compilación a las directivas de omisión al insertar el permiso. Este permiso es un riesgo de seguridad, ya que un usuario malintencionado podría diseñar una canalización para colar 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 git push línea 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 mirror.yml archivo que agregó en el paso anterior. Guarde y ejecute el pipeline.

Solución de problemas

Esta canalización se ejecutará cada vez que haya una inserción en master o en main. Los mantendrá sincronizados siempre que 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 una sugerencia de rama insertada está detrás de su remoto", alguien tendrá que combinar la rama antigua en la nueva rama a mano.

1. Clone el repositorio y cd en su directorio.
2. Consulte 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 abra y complete una solicitud de incorporación de cambios en la nueva rama predeterminada.
6. Después, la canalización de creación de reflejo debe ocuparse de la creación de reflejo de la confirmación de combinación con el valor predeterminado anterior.