Cambiar la rama predeterminada

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

Se le recorrerá el proceso de cambio de la rama predeterminada. También se tratarán otras cosas que debe tener en cuenta y actualizar al realizar este cambio. Por último, veremos una herramienta para facilitar la transición.

Establecer una nueva rama predeterminada

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

Para cambiar la rama predeterminada del repositorio para combinar nuevas solicitudes de extracción, necesita al menos dos ramas. Si solo hay una rama, ya es el valor predeterminado. 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 se denominaba casi siempre master . El nombre alternativo más popular es main . Entre las opciones menos comunes se trunk incluyen y development . Sin restricciones de las herramientas que use o del equipo en el que se encuentra, funcionará cualquier nombre de rama válido.

Actualización de otros sistemas

Al cambiar a una rama predeterminada diferente, otras partes del flujo de trabajo pueden verse afectadas. Tendrá que tener en cuenta estas partes al planear 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 extracción en vuelo

Redestinar cada solicitud de extracción abierta a la nueva rama predeterminada.

Clones existentes

Los nuevos clones del repositorio obtienen la nueva rama predeterminada. Después del cambio, todos los usuarios con un clon existente deben ejecutarse (reemplazando por el nombre de su remoto si es otra cosa) para actualizar su vista de la rama predeterminada git remote set-head origin -aorigin del remoto. Las futuras ramas nuevas 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 deben 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 , esa dirección URL debe &version=GBmybranchname actualizarse. Afortunadamente, la mayoría de los vínculos a la rama predeterminada no tendrán un segmento y version se pueden dejar tal y como están. Además, una vez que elimine la rama predeterminada anterior, los intentos de navegar a ella se pasarán al nuevo valor predeterminado de todos modos.

Creación de reflejo temporal

Un repositorio 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 predeterminado. De este modo, si los usuarios finales siguen presionando el valor predeterminado anterior, no necesitarán volver a realizar el trabajo por su parte. Vamos a usar 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íclas para que se desencadene en la nueva rama predeterminada en lugar de en la anterior.

2. Conceda a la identidad de compilación el permiso Contribuir al repositorio. Vaya a Project ConfiguraciónRepositoriosde almacenamiento (su repositorio)Permisos. Puede haber hasta dos identidades, una para el servicio de compilación de colección 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 a la identidad de compilación las directivas de omisión al insertar el permiso. Este permiso es un riesgo para la seguridad, ya que un usuario malintencionado podría crear una canalización para colar código en un repositorio del proyecto. Cuando ya no se necesite la creación de reflejo, 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 anterior master era 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:
    - master
    - main
 
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 "Azure Repos Git" y "Existing Azure Pipelines YAML file" (Archivo YAML existente) en el asistente. Elija el mirror.yml archivo 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 nuevas confirmaciones no lleguen a ambas ramas simultáneamente.

Si la canalización comienza a dar error con un mensaje de error como "Se rechazaron las actualizaciones porque una sugerencia de rama inserda está detrás de su remota", 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 nueva 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. Inserta la nueva rama y, a continuación, abre y completa una solicitud de extracción en la nueva rama predeterminada.
6. A continuación, la canalización de creación de reflejo debe encargarse de la creación de reflejo de la confirmación de combinación al valor predeterminado anterior.