Adopción de una estrategia de bifurcación de Git

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

Los sistemas de control de versiones distribuidos, como Git, ofrecen flexibilidad en el uso del control de versiones para compartir y administrar código. Su equipo debe encontrar un equilibrio entre esta flexibilidad y la necesidad de colaborar y compartir código de forma coherente.

Los miembros del equipo publican, comparten, revisan e iteran en los cambios de código mediante ramas de Git compartidas con otros usuarios. Adopte una estrategia de rama para su equipo. Puede colaborar mejor y dedicar menos tiempo a administrar el control de versiones y más a desarrollar código.

Las estrategias de rama siguientes se basan en la forma en la que usamos Git aquí en Microsoft. Para obtener más información, consulte Uso de Git en Microsoft.

Simplificación de la estrategia de rama

Mantenga la estrategia de rama simple. Cree la estrategia a partir de estos tres conceptos:

• Use ramas de características para todas las características nuevas y las correcciones de errores.
• Combine ramas de características en la rama principal mediante PR.
• Mantenga una rama principal actualizada y de calidad alta.

Una estrategia que extienda estos conceptos y evite las contradicciones dará lugar a un flujo de trabajo de control de versiones para su equipo que sea coherente y fácil de seguir.

Uso de ramas de característica para el trabajo

Desarrolle sus características y corrija errores en ramas de característica según la rama principal. Estas ramas también se conocen como ramas puntuales. Las ramas de característica separan el trabajo en curso del trabajo completado en la rama principal. Crear y mantener ramas de Git es económico. Incluso pequeñas correcciones y cambios deben tener su propia rama de característica.

La creación de ramas de característica para todos los cambios hace que la revisión del historial sea sencilla. Examine las confirmaciones realizadas en la rama y también la PR que combinó la rama.

Asignación de un nombre a las ramas de característica por convención

Use una convención de nomenclatura coherente para las ramas de característica con el objetivo de identificar el trabajo realizado en la rama. También puede incluir más información en el nombre de la rama, como quién la creó.

Aquí tiene algunas sugerencias para asignar nombres a las ramas de característica:

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• hotfix/description

Nota

Para obtener información sobre cómo establecer directivas para aplicar una estrategia de nomenclatura de rama, consulte Requerir la creación de ramas en carpetas.

Uso de marcas de característica para administrar ramas de ejecución larga

Obtenga más información sobre el uso de marcas de característica en el código.

Revisión y combinación del código con solicitudes de incorporación de cambios

La revisión que tiene lugar en una PR es crítica para mejorar la calidad del código. Solo combine ramas mediante PR que pasen el proceso de revisión. Evite combinar ramas en la rama principal sin una PR.

Las revisiones de las PR tardan en completarse. El equipo debe estar de acuerdo con lo que se espera de los creadores y revisores de PR. Distribuya las responsabilidades de los revisores para compartir ideas entre el equipo y distribuir el conocimiento del código base.

Aquí tiene algunas sugerencias para PR correctas:

• Dos revisores son un número óptimo según la investigación.
• Si el equipo ya tiene un proceso de revisión de código, incorpore las PR a lo que ya está haciendo.
• Tenga cuidado con asignar los mismos revisores a un gran número de PR. Las PR funcionan mejor cuando las responsabilidades del revisor se comparten entre el equipo.
• Proporcione suficiente detalle en la descripción para que los revisores se actualicen rápidamente con los cambios.
• Incluya una versión vinculada o de compilación de los cambios que se ejecutan en un entorno preconfigurado con la PR. Otros pueden probar los cambios fácilmente.

Manutención de una rama principal actualizada y de calidad alta

El código de la rama principal debe superar las pruebas, compilar de forma limpia y estar siempre actualizado. La rama principal necesita estas cualidades para que las ramas de característica creadas por el equipo empiecen a partir de una versión correcta y conocida del código.

Configure una directiva de rama para la rama principal que haga lo siguiente:

• Requiera una PR para combinar código. Este enfoque evita inserciones directas en la rama principal y garantiza la discusión de los cambios propuestos.
• Agregue revisores automáticamente cuando se cree una PR. Los miembros del equipo agregados revisan el código y comentan los cambios en la PR.
• Requiera una compilación correcta para completar una PR. El código combinado en la rama principal debe compilarse limpiamente.

Sugerencia

La canalización de compilación de las PR debe completarse rápidamente, por lo que no interfiere con el proceso de revisión.

Administración de las versiones

Use ramas de versión para coordinar y estabilizar los cambios en una versión del código. Esta rama es de larga duración y no se combina de nuevo en la rama principal en una PR, a diferencia de las ramas de característica. Cree tantas ramas de versión como necesite. Tenga en cuenta que cada rama de versión activa representa otra versión del código que necesita admitir. Bloquee las ramas de versión cuando esté listo para dejar de admitir una versión determinada.

Uso de ramas de versión

Cree una rama de versión desde la rama principal cuando se acerque a la versión u otro hito, como el final de un sprint. Asigne un nombre claro a esta rama que la asocie a la versión, por ejemplo, release/20.

Cree ramas para corregir errores de la rama de versión y combínelas de nuevo en la rama de versión en una PR.

Porte de cambios de vuelta a la rama principal

Asegúrese de que las correcciones llegan a la rama de versión y a la rama principal. Un enfoque consiste en realizar correcciones en la rama de versión y, después, introducir cambios en la rama principal para evitar la regresión en el código. Otro enfoque (y el que emplea el equipo de Azure DevOps) es realizar siempre cambios en la línea principal y, después, portarlos a la rama de versión. Puede obtener más información sobre nuestra estrategia de Flujo de versión.

En este tema, trataremos cómo realizar cambios en la rama de versión y portarlos a la línea principal. Use la selección exclusiva en lugar de combinar para tener un control exacto sobre qué confirmaciones se trasladan a la rama principal. La combinación de la rama de versión en la rama principal puede traer consigo cambios específicos de la versión no deseables en la rama principal.

Actualice la rama principal con un cambio realizado en la rama de versión con estos pasos:

1. Cree una rama de característica nueva fuera de la rama principal para portar los cambios.
2. Seleccione de forma exclusiva los cambios de la rama de versión en la rama de característica nueva.
3. Vuelva a combinar la rama de característica en la rama principal en una segunda PR.

Este flujo de trabajo de rama de versión mantiene intactos los pilares del flujo de trabajo básico: ramas de característica, PR y una rama principal segura que siempre tiene la versión más reciente del código.

¿Por qué no usar etiquetas para versiones?

Otros flujos de trabajo de rama usan etiquetas de Git para marcar una confirmación específica como versión. Las etiquetas son útiles para marcar los puntos en el historial como importantes. Las etiquetas presentan pasos adicionales en el flujo de trabajo que no son necesarios si usa ramas para las versiones.

Las etiquetas se mantienen e insertan por separado de las confirmaciones. Los miembros del equipo pueden olvidar fácilmente etiquetar una confirmación y, después, tener que volver a recorrer el historial para corregir la etiqueta. También puede olvidar el paso adicional de insertar la etiqueta, dejando al siguiente desarrollador trabajando desde una versión anterior del código al admitir la versión.

La estrategia de rama de versión amplía el flujo de trabajo básico de la rama de características para controlar las versiones. El equipo no tiene que adoptar ningún proceso de control de versiones nuevo que no sea la selección exclusiva para migrar los cambios.

Administración de implementaciones

Puede controlar varias implementaciones del código de la misma manera que controla varias versiones. Cree una convención de nomenclatura clara, como deploy/performance-test, y trate las ramas de entorno como ramas de versión. El equipo debe acordar un proceso para actualizar las ramas de implementación con el código de la rama principal. Seleccione de forma exclusiva la corrección de errores en la rama de implementación de vuelta a la rama principal. Siga los mismos pasos que la migración de cambios desde una rama de versión.

Una excepción a esta recomendación es si usa una forma de implementación continua. Use Azure Pipelines al trabajar con la implementación continua para promover compilaciones de la rama principal a los destinos de implementación.