Combinación de estrategias y combinación de squash

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

Cuando se completa una solicitud de incorporación de cambios, la rama de tema se combina en la rama predeterminada, normalmente main. Esta combinación agrega las confirmaciones de la rama de tema a la rama principal y crea una confirmación de combinación para conciliar los conflictos entre la rama predeterminada y la de tema. Los comentarios y debates de la solicitud de incorporación de cambios proporcionan contexto adicional para los cambios realizados en la rama puntual.

El historial de confirmaciones de la rama main (u otra rama predeterminada) no sigue una línea recta, debido al historial de ramas puntuales relacionadas. A medida que un proyecto crece, aumenta el número de ramas puntuales en las que se trabaja al mismo tiempo, lo que hace que el historial de ramas predeterminadas sea cada vez más difícil de seguir.

La rama predeterminada es una representación precisa del historial de cada rama puntual, pero es difícil de usar para responder a preguntas más amplias sobre el desarrollo del proyecto.

Fusión mediante combinación con "squash"

La fusión mediante combinación con "squash" es una opción de combinación que permite condensar el historial de Git de ramas puntuales al completar una solicitud de incorporación de cambios. En lugar de que cada confirmación en la rama puntual se agregue al historial de la rama predeterminada, una fusión mediante combinación con "squash" agrega todos los cambios de archivo a una única confirmación nueva en la rama predeterminada. La confirmación de fusión mediante combinación con "squash" no tiene una referencia a la rama puntual; generará una nueva confirmación con todos los cambios de la rama de tema. Además, se recomienda eliminar la rama puntual para evitar confusiones.

Una manera sencilla de pensar en esto es que la fusión mediante combinación con "squash" le proporciona solo los cambios de archivo y una combinación normal le proporciona los cambios de archivo y el historial de confirmaciones.

¿Cuál es la utilidad de una fusión mediante combinación con "squash"?

La fusión mediante combinación con "squash" mantiene los historiales de ramas predeterminadas limpios y fáciles de seguir sin exigir cambios de flujo de trabajo en el equipo. Los colaboradores de la rama puntual trabajan como quieren en ella y las ramas predeterminadas mantienen un historial lineal gracias al uso de fusiones mediante combinación con "squash". El historial de confirmaciones de una rama main actualizada con fusiones mediante combinación con "squash" tiene una confirmación para cada rama combinada. Puede recorrer este historial para averiguar exactamente cuándo se ha realizado el trabajo.

Consideraciones sobre la fusión mediante combinación con "squash"

La fusión mediante combinación con "squash" condensa el historial de cambios en la rama predeterminada, por lo que es importante trabajar con el equipo para decidir cuándo se debe realizar o cuándo se quiere mantener el historial de confirmaciones completo de una rama puntual. Cuando se fusiona mediante combinación con "squash", se recomienda eliminar la rama de origen. La eliminación de la rama de origen evita confusiones, ya que la propia rama puntual no tiene una confirmación que la combine en la rama predeterminada.

Finalización de solicitudes de incorporación de cambios con fusión mediante combinación con "squash"

Puede elegir la fusión mediante combinación con "squash" al completar una solicitud de incorporación de cambios en Azure Repos.

Elija Confirmación de squash en Tipo de combinación en el cuadro de diálogo Completar solicitud de incorporación de cambios para combinar la rama puntual.

Varias bases de combinación

En la pestaña Archivos de una solicitud de incorporación de cambios se detectan las diferencias mediante una comparación triple. El algoritmo tiene en cuenta la última confirmación de la rama de destino, la última confirmación de la rama de origen y su base de combinación común (es decir, el mejor antecesor común). El algoritmo es un método rápido, rentable y confiable para detectar cambios. Desafortunadamente, en algunos casos, hay más de una base verdadera. En la mayoría de los repositorios, esta situación es poco frecuente, pero puede ser común en repositorios grandes con muchos usuarios activos. Puede comprobar manualmente si existen varias bases de fusión entre las ramas. Para ello, ejecute el comando git merge-base --all feature master. Azure DevOps detecta la existencia de varias bases de fusión en cada solicitud de incorporación de cambios. Cuando se detectan, en Azure DevOps saldrá el mensaje "Se han detectado varias bases de fusión. La lista de confirmaciones mostradas podría estar incompleta" en la solicitud de incorporación de cambios. Aunque Azure DevOps ejecute la detección de varias bases de fusión, no se comprueba si la base de fusión potencial ya se ha combinado o no. Dicha comprobación se realiza a través de git merge-base. Este es el motivo por el que en Azure DevOps puede aparecer el mensaje aunque git merge-base solo avise de una base de fusión.

Nota:

En caso de que haya perdido los cambios durante la revisión de una solicitud de incorporación de cambios, confirme que esto no lo causen las diferentes bases de fusión.

Azure DevOps detecta los siguientes escenarios como varias bases (las bases de fusión se indican mediante los números 1 y 2):

• Combinaciones cruzadas (también conocidas como entrecruzadas) entre diferentes ramas (notificadas a través de Azure DevOps, así como git merge-base)

---1---o---A
    \ /
     X
    / \
---2---o---o---B

• Combinación de una rama con otras dos (notificada a través de Azure DevOps, pero no mediante git merge-base que elimina la base de fusión 2)

---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B

• Cómo actuar ante los efectos de las reversiones de la rama principal, por ejemplo, modificar la confirmación de fusión

*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init

• Reutilización activa de ramas de características
• Otras manipulaciones no intuitivas y complejas con reversiones, selecciones exclusivas y combinaciones

La detección de base de combinación múltiple forma parte del reconocimiento de la seguridad. Si hay varias bases de combinación, es posible que el algoritmo de diferencias de archivo de la interfaz de usuario no detecte correctamente los cambios de archivo, en función de la base de combinación que elija. Si los archivos de la solicitud de incorporación de cambios tienen versiones diferentes entre las bases de combinación, se produce una advertencia de varias bases de combinación.

Revise la documentación oficial de Git para más información.

Posibles riesgos de seguridad de la combinación desde varias bases

• Un usuario malintencionado podría abusar del algoritmo de la interfaz de usuario para confirmar cambios malintencionados que no están presentes en la solicitud de incorporación de cambios.
• Si los cambios propuestos en la solicitud de incorporación de cambios ya están en la rama de destino, se muestran en la pestaña Archivos, pero es posible que no desencadenen directivas de rama asignadas a los cambios de carpeta.
• Es posible que dos conjuntos de cambios en los mismos archivos de varias bases de combinación no estén presentes en la solicitud de incorporación de cambios. Ese caso podría crear lagunas lógicas traicioneras.

Procedimiento para resolver el problema de varias bases de combinación

Tener varias bases de combinación no es algo necesariamente incorrecto, pero debe comprobar que todo esté bien. Para deshacerse de varias bases de combinación, vincule las ramas a un único antecesor común por medio la fusión mediante cambio de base de la rama en el destino o la combinación del destino en la rama. Estas acciones eliminan el mensaje de advertencia y le ayudan a comprobar si los cambios reales son correctos.

Un enfoque consiste en restablecer temporalmente y guardar provisionalmente el progreso antes de la fusión mediante cambio de base o la combinación. Después, puede crear una rama o fusionar mediante cambio de base una vacía, y aplicar los cambios desde un punto claro. Es posible que este proceso necesite una inserción forzada en el entorno remoto si los cambios ya están allí.

Procedimiento para evitar el problema de varias bases de combinación

Estas son sugerencias generales para evitar el problema de varias bases de combinación:

• Al preparar una solicitud de incorporación de cambios, cree ramas de características a partir de las versiones más recientes de la rama principal o de versión.
• Evite crear ramas que no se originen directamente desde ramas estables del repositorio, a menos que sea necesario.

Qué hacer si vuelve a aparecer el problema de varias bases de combinación

En repositorios grandes con muchos colaboradores activos, este problema puede ser especialmente incómodo. Incluso si se deshace de varias bases mediante la combinación, es posible que la situación se repita. Si alguien cierra una solicitud de incorporación de cambios de larga duración, se puede volver a crear la situación. Aunque se ejecuten directivas de compilación y pruebas, no tiene ningún medio para completar la solicitud de incorporación de cambios. Una solución podría ser restablecer e iniciar una nueva rama. Si no cambia nada, es probable que los cambios sean claros, incluso si la situación se repite.

Pasos siguientes

• Resolución de conflictos de combinación
• Completar una solicitud de incorporación de cambios
• Acerca de las solicitudes de incorporación de cambios