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.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Cuando se completa una solicitud de incorporación de cambios, se combina la rama de tema 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 de tema. 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 . - Clone o contribuya al código en proyectos privados: miembro del grupo de seguridad Colaboradores o de los permisos correspondientes del proyecto. - Establecer permisos de rama o repositorio: administre permisos para la rama o el repositorio. - Cambiar la rama predeterminada: edite los permisos de directivas para el repositorio. - Importar un repositorio: miembro del grupo de seguridad Administradores de proyectos o del nivel de proyecto de Git Crear conjunto de permisos de repositorio en Permitir. Para obtener más información, consulte Establecimiento de permisos de repositorio de Git. |
| Servicios | Repositorios habilitados. |
| Herramientas | Optional. Use los comandos az repos : CLI de Azure DevOps. |
Nota:
En proyectos públicos, los usuarios con acceso a las partes interesadas tienen acceso completo a Azure Repos, incluida la visualización, la clonación y la contribución al código.
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Miembro de un proyecto. |
| Permisos | - Ver código: al menos acceso básico . - Clone o contribuya al código: miembro del grupo de seguridad Colaboradores o de los permisos correspondientes del proyecto. |
| Servicios | Repositorios habilitados. |
Combinación de squash
La combinación de squash es una opción de combinación que permite condensar el historial de Git de las ramas de temas 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 combinación de squash no tiene una referencia a la rama de tema. 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 la combinación de squash proporciona solo los cambios de archivo y una combinación normal proporciona los cambios de archivo y el historial de confirmaciones.
¿Cómo resulta útil una combinación de squash?
La combinación de squash mantiene los historiales de rama predeterminados limpios y fáciles de seguir sin exigir cambios de flujo de trabajo en su equipo. Los colaboradores de la rama de temas funcionan cómo quieren en la rama de tema y las ramas predeterminadas mantienen un historial lineal mediante combinaciones de squash. El historial de confirmaciones de una main rama actualizada con combinaciones de squash tiene una confirmación para cada rama combinada. Puede recorrer este historial para averiguar exactamente cuándo se realizó el trabajo.
Consideraciones al combinar la combinación de squash
La combinación de squash condensa el historial de cambios en la rama predeterminada, por lo que es importante trabajar con el equipo para decidir cuándo combinar combinación frente a mantener el historial de confirmaciones completo de una rama de tema. Cuando se combina squash, se recomienda eliminar la rama de origen. La eliminación de la rama de origen impide la confusión, ya que la propia rama de tema no tiene una confirmación que la combine en la rama predeterminada.
Completar solicitudes de incorporación de cambios con combinación de squash
Puede elegir combinar combinación 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 del tema.
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. Puede comprobar manualmente si existen varias bases de combinación entre las ramas. Para ello, ejecute el git merge-base --all feature master comando . Azure DevOps detecta la existencia de varias bases de combinación para cada solicitud de incorporación de cambios. Cuando se detectan, Azure DevOps muestra el mensaje "Se detectaron varias bases de combinación. La lista de confirmaciones mostradas podría estar incompleta para 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 una revisión de pr, asegúrese de que varias bases de combinación no sean la causa principal.
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 criss-cross) entre diferentes ramas (notificadas por Azure DevOps y
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Combinación de una rama con otras dos (notificada por Azure DevOps, pero no por
git merge-baseeso elimina la base de mezcla 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Controlar las consecuencias de la reversión de la rama principal, por ejemplo, modificar la confirmación de combinació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 involuntarias y convoluidas con reversión, selectores de cereza y combinaciones
La detección de varias bases de combinación 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 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 brechas lógicas traicioneras.
Cómo resolver el problema de varias bases de combinación
Tener varias bases de combinación no es necesariamente incorrecta, pero debe comprobar que todo está bien. Para deshacerse de varias bases de combinación, asote las ramas a un único antecesor común mediante la rebasificación de la rama en el destino o la combinación de destino en la rama. Esas acciones se eliminan del mensaje de advertencia y le ayudan a comprobar si los cambios reales están bien.
Un enfoque consiste en restablecer temporalmente y guardar el progreso antes de rebasar o combinar. A continuación, puede crear una nueva rama o volver a base de una vacía y aplicar los cambios desde un punto claro. Este proceso podría requerir una inserción forzada en remoto si los cambios ya están allí.
Cómo 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 inconveniente. Incluso si se deshace de varias bases mediante combinación, es posible que la situación vuelva a aparecer. Si alguien cierra una solicitud de incorporación de cambios de larga duración, puede volver a crear la situación. Aunque se ejecutan directivas de compilación y pruebas, no tiene ningún medio para completar la solicitud de incorporación de cambios. El restablecimiento e inicio de una nueva rama puede ayudar. Si no se cambia nada, es probable que los cambios estén claros, incluso si la situación se repite.