Adopción de una estrategia de bifurcación de Git
Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015
Los sistemas de control de versiones distribuidos, como Git, ofrecen flexibilidad en la forma de usar el control de versiones para compartir y administrar código. El 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 iteren los cambios de código a través de ramas de Git compartidas con otros usuarios. Adopte una estrategia de bifurcación para su equipo. Puede colaborar mejor y dedicar menos tiempo a administrar el control de versiones y más tiempo a desarrollar código.
Las siguientes estrategias de bifurcación se basan en la forma en que usamos Git aquí en Microsoft. Para obtener más información, consulte Uso de Git en Microsoft.
Mantener la estrategia de la rama sencilla
Mantenga la estrategia de la rama sencilla. Cree su estrategia a partir de estos tres conceptos:
- Use ramas de características para todas las nuevas características y correcciones de errores.
- Combine ramas de características en la rama principal mediante solicitudes de extracción.
- Mantenga una rama principal actualizada y de alta calidad.
Una estrategia que extienda estos conceptos y evite las incoherencias dará como resultado un flujo de trabajo de control de versiones para el equipo que sea coherente y fácil de seguir.
Uso de ramas de características para su trabajo
Desarrolle sus características y corrija errores en ramas de características basadas en la rama principal. Estas ramas también se conocen como ramas de tema. Las ramas de características aíslan el trabajo en curso del trabajo completado en la rama principal. Las ramas de Git son económicas de crear y mantener. Incluso las correcciones y los cambios pequeños deben tener su propia rama de características.
La creación de ramas de características para todos los cambios simplifica la revisión del historial. Mire las confirmaciones realizadas en la rama y vea la solicitud de extracción que ha combinado la rama.
Asigne un nombre a las ramas de características por convención
Use una convención de nomenclatura coherente para las ramas de características a fin de identificar el trabajo realizado en la rama. También puede incluir otra información en el nombre de la rama, como quién creó la rama.
Algunas sugerencias para asignar un nombre a las ramas de características:
- users/username/description
- users/username/workitem
- bugfix/description
- feature/feature-name
- feature/feature-area/feature-name
- revisión y descripción
Nota
Para obtener información sobre cómo establecer directivas para aplicar una estrategia de nomenclatura de rama, vea Requerir carpetas de rama.
Uso de marcas de características para administrar ramas de ejecución larga
Obtenga más información sobre el uso de marcas de características 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 solicitud de extracción es fundamental para mejorar la calidad del código. Solo se combinan ramas a través de solicitudes de extracción que pasan el proceso de revisión. Evite combinar ramas con la rama principal sin una solicitud de extracción.
Las revisiones de las solicitudes de extracción llevan tiempo en completarse. El equipo debe estar de acuerdo en lo que se espera de los creadores y revisores de las solicitudes de extracción. Distribuya las responsabilidades del revisor para compartir ideas entre el equipo y distribuir el conocimiento del código base.
Algunas sugerencias para solicitudes de extracción correctas:
- Dos revisores es un número óptimo basado en la investigación.
- Si el equipo ya tiene un proceso de revisión de código, lleve las solicitudes de extracción a lo que ya está haciendo.
- Asigne los mismos revisores a un gran número de solicitudes de extracción. Las solicitudes de extracción funcionan mejor cuando las responsabilidades del revisor se comparten entre el equipo.
- Proporcione suficientes detalles en la descripción para poner rápidamente a los revisores al día con los cambios.
- Incluya una versión de compilación o vinculada de los cambios que se ejecutan en un entorno con fases con la solicitud de extracción. Otros usuarios pueden probar fácilmente los cambios.
Mantener una rama principal actualizada y de alta calidad
El código de la rama principal debe superar pruebas, compilarse correctamente y estar siempre al día. La rama principal necesita estas calidades para que las ramas de características creadas por el equipo comiencen desde una buena versión conocida del código.
Configure una directiva de rama para la rama principal que:
- Requiere una solicitud de extracción para combinar código. Este enfoque evita las inserciones directas en la rama principal y garantiza la discusión de los cambios propuestos.
- Agrega automáticamente revisores cuando se crea una solicitud de extracción. Los miembros del equipo agregados revisan el código y comentan los cambios en la solicitud de extracción.
- Requiere una compilación correcta para completar una solicitud de extracción. El código combinado en la rama principal debe compilarse correctamente.
Sugerencia
La canalización de compilación para las solicitudes de extracción debe completarse rápidamente, por lo que no interfiere con el proceso de revisión.
Administración de 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 solicitud de extracción, a diferencia de las ramas de características. 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 acerca a la versión u otro hito, como el final de un sprint. Asigne un nombre claro a esta rama asociándolo a la versión, por ejemplo, release/20.
Cree ramas para corregir errores de la rama de versión y combinarlos de nuevo en la rama de versión en una solicitud de extracción.
Cambios de puerto de vuelta a la rama principal
Asegúrese de que las correcciones se aterrizó tanto en la rama de versión como en la rama principal. Un enfoque es realizar correcciones en la rama de versión y, a continuación, llevar los cambios a la rama principal para evitar la regresión en el código. Otro enfoque (y el empleado por el equipo de Azure DevOps) es realizar siempre cambios en la línea principal y, a continuación, portabilidad a la rama de versión. Puede leer más sobre nuestra estrategia de Flow lanzamiento.
En este tema, se tratarán los cambios realizados en la rama de versión y su porte a la línea principal. Use la selección de guisos en lugar de combinar para tener un control exacto sobre qué confirmaciones se portan de nuevo a la rama principal. La combinación de la rama de características en la rama principal puede aportar cambios específicos de la versión que no desee en la rama principal.
Actualice la rama principal con un cambio realizado en la rama de versión con estos pasos:
- Cree una nueva rama de características fuera de la rama principal para porte los cambios.
- Elija los cambios de la rama de versión a la nueva rama de características.
- Vuelva a combinar la rama de características en la rama principal en una segunda solicitud de extracción.
Este flujo de trabajo de la rama de versión mantiene intactos los pilares del flujo de trabajo básico: ramas de características, solicitudes de extracción y una rama principal segura que siempre tiene la versión más reciente del código.
¿Por qué no usar etiquetas para las versiones?
Otros flujos de trabajo de bifurcación usan etiquetas de Git para marcar una confirmación específica como una versión. Las etiquetas son útiles para marcar los puntos del 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 perder fácilmente el etiquetado de una confirmación y, después, tener que volver a través del historial para corregir la etiqueta. También puede olvidar el paso adicional para insertar la etiqueta y dejar que el siguiente desarrollador trabaje 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. Su equipo no tiene que adoptar ningún nuevo proceso de control de versiones que no sea la selección de la guión para los cambios de puerto.
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. Correcciones de errores de selección de guión en la rama de implementación de vuelta a la rama principal. Siga los mismos pasos que para porte los cambios de 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 las compilaciones de la rama principal a los destinos de implementación.