Exploración del modelo de rama de Git para la entrega continua

3 minutos

El propósito de escribir código es enviar mejoras al software.

Un modelo de bifurcación que introduce demasiada sobrecarga en el proceso no ayuda a aumentar la velocidad de entrega de los cambios a los clientes: el desarrollo de un modelo de bifurcación le da suficiente margen para no enviar cambios de mala calidad. pero que, al mismo tiempo, no introduzca demasiados procesos que lo ralenticen.

Internet está lleno de estrategias de bifurcación para Git. Aunque no se pueden considerar correctas o incorrectas, su equipo necesita encontrar la estrategia de bifurcación perfecta.

Aprenderá a usar siempre la combinación de ramas de características y solicitudes de incorporación de cambios que le permita tener una rama principal lista para el envío.

Preparación

Veamos los principios de lo que sugerimos:

Rama principal:
- La rama principal es la única manera de lanzar algo a producción.
- La rama principal siempre debe estar en un estado listo para el lanzamiento.
- Proteja la rama principal con directivas de rama.
- Los cambios realizados en la rama principal fluyen solo a través de solicitudes de incorporación de cambios.
- Etiquete todas las versiones de la rama principal con etiquetas de Git.
Rama de características:
- Use ramas de características para todas las características nuevas y las correcciones de errores.
- Use marcas de características para administrar ramas de características de ejecución larga.
- Los cambios de las ramas de características a la rama principal solo fluyen a través de solicitudes de incorporación de cambios.
- Asigne un nombre a la característica para reflejar su propósito.
La rama de versión:
- Cree una rama de versión dedicada a partir de una rama de características estable para preparar la implementación.
- Asegúrese de que la rama de lanzamiento se somete a pruebas exhaustivas y a esfuerzos de estabilización.
- Aplique las correcciones de errores y los cambios necesarios a la rama de lanzamiento antes de la implementación.
- Etiquete las versiones en la rama de versión para marcar hitos significativos.
Lista de ramas:
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
Solicitudes de incorporación de cambios:
- Revise y combine código con solicitudes de incorporación de cambios.
- Automatice lo que inspeccione y valídelo como parte de las solicitudes de incorporación de cambios.
- Realice un seguimiento de la duración de la finalización de la solicitud de incorporación de cambios y establezca objetivos para reducir el tiempo que tarda.

Usaremos la aplicación myWebApp creada en los ejercicios anteriores. Consulte Descripción del trabajo local con GIT.

En esta receta, usaremos tres extensiones de moda del marketplace:

CLI de Azure: se trata de una interfaz de la línea de comandos para Azure.
CLI de Azure DevOps: es una extensión de la CLI de Azure para trabajar con Azure DevOps y Azure DevOps Server, diseñada para integrarse sin problemas con Git, canalizaciones de CI y herramientas de Agile. Con la CLI de Azure DevOps, puede contribuir a los proyectos sin necesidad de salir de la línea de comandos. La CLI se ejecuta Windows, Linux y Mac.
Conflicto de combinación de solicitudes de incorporación de cambios de Git: esta extensión de código abierto creada por Microsoft DevLabs permite revisar y resolver conflictos de combinación de solicitudes de incorporación de cambios en la web. Para que se pueda completar una solicitud de incorporación de cambios de Git, es necesario resolver los conflictos con la rama de destino. Con esta extensión, puede resolver estos conflictos en la web como parte de la combinación de solicitudes de incorporación de cambios, en lugar de realizar la combinación y resolver los conflictos en un clon local.

La CLI de Azure DevOps admite la devolución de resultados de consulta en JSON, JSONC, tabla, TSV y ninguno. Puede configurar sus preferencias mediante el comando configure.

Cómo hacerlo

Importante

Debe tener el proyecto creado en la primera ruta de aprendizaje: Descripción del trabajo local con GIT.

Después de clonar la rama principal en un repositorio local, cree una rama de características (myFeature-1):

myWebApp
```
git checkout -b feature/myFeature-1
```
Salida:

Se ha cambiado a una nueva rama "feature/myFeature-1".
Ejecute el comando de la rama de Git para ver todas las ramas. La rama que aparece con un asterisco es la rama "actualmente extraída del repositorio":

myWebApp
```
git branch
```
Salida:

feature/myFeature-1

principal
Realice un cambio en el archivo Program.cs en la rama feature/myFeature-1:

myWebApp
```
notepad Program.cs
```
Agregue al "stage" los cambios y confirme localmente y, luego, publique la rama en el repositorio remoto:

myWebApp
```
git status
```
Salida:

On branch feature/myFeature-1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Program.cs.

myWebApp
```
git add .
git commit -m "Feature 1 added to Program.cs"
```
Salida:

[feature/myFeature-1 70f67b2] característica 1 agregada al archivo program.cs 1 cambiado, 1 inserción(+).

myWebApp
```
git push -u origin feature/myFeature-1
```
Salida:

Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Analyzing objects... (3/3) (10 ms) remote: Storing packfile... done (44 ms) remote: Storing index... done (62 ms) To https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

El repositorio remoto muestra el historial de los cambios:
Configure Azure DevOps CLI para su organización y proyecto. Reemplace el nombre de la organización y de proyecto:
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
Cree una solicitud de incorporación de cambios (mediante la CLI de Azure DevOps) para revisar los cambios en la rama feature-1:
```
az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open
```
Use el modificador --open al generar la solicitud de incorporación de cambios para abrirla en un explorador web una vez creada. El modificador --deletesource-branch se puede usar para eliminar la rama una vez que se ha completado la solicitud de incorporación de cambios. Además, considere la posibilidad de usar --auto-complete para completar el proceso automáticamente cuando se hayan pasado todas las directivas y la rama de origen se pueda combinar en la rama de destino.

Nota:

Para obtener más información sobre el parámetro az repos pr create, consulte Creación de una solicitud de incorporación de cambios para revisar y combinar código.

El equipo revisa conjuntamente los cambios de código y aprueba la solicitud de incorporación de cambios:

La rama principal está lista para su lanzamiento. El equipo etiqueta la rama principal con el número de versión:
Empiece a trabajar en feature-2. Cree una rama en el repositorio remoto desde la rama principal y realice la extracción del repositorio localmente:

myWebApp
```
git push origin main:refs/heads/feature/myFeature-2
```
Salida:

Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp
```
git checkout feature/myFeature-2
```
Salida:

Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

Modifique Program.cs cambiando la misma línea de comentario en el código que cambió en feature-1.

public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Confirme los cambios localmente, envíelos al repositorio remoto y, luego, realice una solicitud de incorporación de cambios para combinar los cambios de feature/myFeature-2 en la rama principal:
```
az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open
```
Se notifica un error crítico en producción en la versión feature-1 con la solicitud de incorporación de cambios en curso. Para investigar el problema, debe depurar con la versión de código implementada actualmente en producción. Para investigar el problema, cree una rama fof con la etiqueta release_feature1:

myWebApp
```
git checkout -b fof/bug-1 release_feature1
```
Salida:

Se ha cambiado a una nueva rama, "fof/bug-1".

Modifique Program.cs cambiando la misma línea de código que cambió en la versión feature-1:

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Agregue al "stage" y confirme los cambios localmente y, luego, envíe los cambios al repositorio remoto:

myWebApp
```
git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1
```
Salida:

To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.
Inmediatamente después de que los cambios se hayan implementado en producción, etiquete la rama fof_bug-1 con la etiqueta release_bug-1 y, después, realice una solicitud de incorporación de cambios para combinar los cambios de fof/bug-1 de nuevo en la rama principal:
```
az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open
```
Como parte de la solicitud de incorporación de cambios, se elimina la rama. Aun así, todavía puede hacer referencia a todo el historial mediante la etiqueta.

Ahora que ya hemos realizado la corrección de errores críticos, revisemos la solicitud de incorporación de cambios de feature-2.

La página de ramas muestra claramente que la rama feature/myFeature-2 está un cambio por delante de la rama principal y dos por detrás de la rama principal:

Si ha intentado aprobar la solicitud de incorporación de cambios, verá un mensaje de error en el que se le informa de un conflicto de combinación:
La extensión de resolución de conflictos de combinación de solicitudes de incorporación de cambios de Git permite resolver conflictos de combinación directamente en el explorador. Vaya a la pestaña de conflictos y haga clic en Program.cs para resolver los conflictos de combinación:

La interfaz de usuario permite tomar el origen y el destino, agregar cambios personalizados, revisar y enviar la combinación. Una vez que se han combinado los cambios, se completa la solicitud de incorporación de cambios.

En este punto, puede crear una rama de versión basada en la corrección de errores críticos implementada en la rama fof/bug-1 y fusionada en master. Utilizando el comando git checkout, cree una rama de versión dedicada a partir de la rama principal.

git checkout -b release/v1.1 main

Este comando crea una nueva rama llamada versión/v1.1 basada en la rama principal.

A medida que se alcancen hitos significativos durante el proceso de publicación, etiquete las publicaciones en la rama de publicación mediante etiquetas Git. Las etiquetas sirven como marcadores para indicar versiones específicas del software.

git tag -a v1.1 -m "Release version 1.1"

Este comando crea una etiqueta llamada v1.1 para marcar la versión de lanzamiento 1.1 en la rama de lanzamiento.

Funcionamiento

Hemos aprendido la forma en que el modelo de rama de Git ofrece la flexibilidad de trabajar en las características en paralelo mediante la creación de una rama para cada característica.

El flujo de trabajo de solicitud de incorporación de cambios permite revisar los cambios en el código mediante las directivas de rama.

Las etiquetas de Git son una excelente manera de registrar hitos, como la versión del código publicado. Las etiquetas ofrecen una manera de crear ramas a partir de etiquetas.

Hemos creado una rama a partir de una etiqueta de versión anterior para corregir un error crítico en producción.

La vista de ramas del portal web facilita la identificación de las ramas situadas delante de la rama principal. Además, fuerza un conflicto de combinación si alguna solicitud de incorporación de cambios en curso intenta combinarse con la rama principal sin resolver los conflictos de combinación.

Un modelo de bifurcación lean permite crear ramas de corta duración y enviar cambios de calidad a producción con más rapidez.

Exploración del modelo de rama de Git para la entrega continua

Preparación

Cómo hacerlo

Funcionamiento

Comentarios