Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Cuando se completa una solicitud de incorporación de cambios, la rama de tema se combina en la rama predeterminada, normalmente main. Esta fusión añade los commits de la rama temática a tu rama principal y crea un commit de fusión para resolver los conflictos entre la rama predeterminada y la rama temática. Los comentarios y la discusión de la solicitud de incorporación de cambios proporcionan más contexto para los cambios realizados en la rama de tema.
El historial de confirmaciones de la main rama (u otra rama predeterminada) no sigue una línea recta, debido al historial de ramas de temas relacionados. A medida que un proyecto crece más, el número de ramas de temas en las que se ha trabajado al mismo tiempo aumenta, lo que hace que el historial de ramas predeterminado sea cada vez más difícil de seguir.
La rama predeterminada es una representación precisa del historial de cada rama de tema, pero es difícil de usar para responder a preguntas más amplias sobre el desarrollo del proyecto.
Prerrequisitos
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Miembro de un proyecto. |
| Permisos | - Ver código en proyectos privados: al menos acceso básico. - Clonar o contribuir al código en proyectos privados: ser miembro del grupo de seguridad Contribuidores o contar con los permisos correspondientes en el proyecto. - Establecer permisos de rama o repositorio: administre permisos para la rama o el repositorio. - Establezca directivas de rama, comprobaciones de estado o cambie la rama predeterminada: edite el permiso de directivas para el repositorio o rama o la pertenencia al grupo de seguridad administradores de Project. - Importar un repositorio: miembro del grupo de seguridad de Administradores de proyecto o repositorio Git a nivel de proyecto Crear repositorio con la opción Permitir. Para obtener más información, consulte Establecimiento de permisos de repositorio de Git. |
| Servicios | Repositorios habilitados. |
| Herramientas | Optional. Uso de az repos comandos: CLI de Azure DevOps. |
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Miembro de un proyecto. |
| Permisos | - Ver código: al menos acceso básico. - Clonar o contribuir al código: Miembro de la Colaboradores grupo de seguridad o los permisos correspondientes en el proyecto. |
| Servicios | Repositorios habilitados. |
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 agregar cada confirmación en la rama de tema al historial de la rama predeterminada, una combinación de 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 por "squash" no tiene una referencia a la rama temática. Genera una nueva confirmación que contiene todos los cambios de la rama de tema. Se recomienda eliminar la rama de tema para evitar cualquier confusión.
Una manera sencilla de pensar en esto es que un squash merge proporciona solo los cambios de archivo, mientras que una combinación normal proporciona tanto los cambios de archivo como el historial de commits.
¿Cómo resulta útil un squash merge?
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 de tema 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 realizó 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 de tema. Cuando se Fusión mediante combinación con "squash", se recomienda eliminar la rama de origen. Eliminar la rama de origen evita confusiones, ya que la rama temática en sí misma no tiene un commit que la fusione 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
La pestaña Archivos de una solicitud de incorporación de cambios detecta diferencias mediante una comparación de tres lados. 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, por ejemplo, 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 en repositorios grandes con muchos usuarios activos, puede ser común. Compruebe manualmente si existen varias bases de fusión entre las ramas. Para ello, ejecute el git merge-base --all feature master comando . Azure DevOps detecta varias bases de combinación para cada PR. Cuando se detectan, Azure DevOps muestra el mensaje "Se detectaron varias bases de combinación. La lista de confirmaciones mostradas podría estar incompleta" en la solicitud de incorporación de cambios. Aunque Azure DevOps ejecuta la detección de varias bases de combinación, no comprueba si la base de combinación potencial ya se ha combinado o no. Dicha comprobación se realiza mediante git merge-base. Este es el motivo por el que Azure DevOps puede mostrar el mensaje incluso cuando git merge-base solo notifica una base de combinació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.
Los siguientes escenarios de ejemplo se detectan en Azure DevOps como varias bases, con las bases de combinación indicadas por los números uno y dos:
- Combinaciones cruzadas (también conocidas como entrecruzadas) entre diferentes ramas (notificadas a través de Azure DevOps y
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-baseque 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 funcionalidades
- 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 diferencia 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 obtener más detalles.
Posibles riesgos de seguridad de la combinación de 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 el PR ya están en la rama de destino, se muestran en la pestaña Archivos, pero es posible que no desencadenen las políticas de rama que están vinculadas a cambios que afectan a las carpetas.
- 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 brechas lógicas traicioneras.
Procedimiento para resolver el problema de varias bases de combinación
Tener varias bases de fusión no es necesariamente malo, pero debiera verificar 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. Esas 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. A continuación, puede crear una nueva rama o rebasar una rama vacía, y aplicar sus cambios desde un punto de partida claro. Es posible que este proceso necesite una inserción forzada en el entorno remoto si los cambios ya están allí.
Cómo evitar el problema relacionado con varias bases de fusión
Estos son consejos generales para evitar el problema de múltiples bases de fusió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 reaparecer el problema de bases de fusión múltiples
En repositorios grandes con muchos colaboradores activos, este problema puede ser especialmente inconveniente. Incluso si se deshace de varias bases mediante fusión, es posible que la situación pueda repetirse. Si alguien cierra una pull request de larga duración, eso puede volver a generar la misma 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. Restablecer y comenzar una nueva rama podría ayudar. Si no se cambia nada, es probable que los cambios estén claros, incluso si la situación se repite.