Aplicación de cambios con fusión mediante cambio de base

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

Visual Studio 2019 | Visual Studio 2022

Git mantiene automáticamente un historial de desarrollo en una rama vinculando cada nueva confirmación a su predecesor. Al combinar una rama en otra, el historial puede ser menos sencillo. Por ejemplo, una combinación sin avance rápido combina líneas de desarrollo divergentes mediante la creación de una confirmación de combinación con varias predecesoras. Por el contrario, una rebase de Git combina líneas de desarrollo divergentes sin crear una confirmación de combinación, lo que da como resultado un historial de confirmaciones más sencillo, pero pierde información sobre la combinación. La elección del tipo de combinación probablemente se ve afectada por si desea conservar un registro de la combinación o simplificar el historial de confirmaciones.

En este artículo se describe cuándo usar una rebase en lugar de una combinación sin avance rápido y se proporcionan procedimientos para las siguientes tareas:

Rebase la rama local
Forzar la inserción de la rama local después de una rebase
Base interactiva para las confirmaciones locales de squash

Para obtener información general sobre el flujo de trabajo de Git, consulte tutorial de Git de Azure Repos.

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 repositorios 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.

Rebase la rama local

Git rebase integra confirmaciones de una rama de origen en la rama local actual (rama de destino). La rama de origen permanece sin cambios. Para la comparación, la base de datos de Git y otros tipos de combinación se muestran en el diagrama siguiente.

Diagrama que muestra las confirmaciones antes y después al usar la base de Git.

La base de Git vuelve a ejecutar el historial de confirmaciones de la rama de destino para que contenga todas las confirmaciones de rama de origen, seguidas de todas las confirmaciones de rama de destino desde la última confirmación común. Otra manera de verlo es que una base reproduce los cambios en la rama de destino sobre el historial de la rama de origen. En concreto, Git rebase cambia la secuencia de las confirmaciones de la rama de destino existente, que no es el caso de las otras estrategias de combinación. En el diagrama anterior, la confirmación K' contiene los mismos cambios que K, pero tiene un nuevo identificador de confirmación porque se vincula a la confirmación E en lugar de C.

Durante una rebase, si un cambio de rama de origen entra en conflicto con un cambio de rama de destino, Git le pedirá que resuelva el conflicto de combinación. Puede resolver conflictos de combinación durante una rebase de la misma manera que se resuelven los conflictos de combinación durante una combinación.

Rebase frente a combinación sin avance rápido

La rebasificación de Git da como resultado un historial de confirmaciones más sencillo pero menos exacto que una combinación sin avance rápido , lo que se conoce como combinación triple o verdadera . Cuando desee un registro de una combinación en el historial de confirmaciones, use una combinación sin avance rápido.

Si es la única persona que trabaja en una rama de característica o de corrección de errores, considere la posibilidad de usar una base para integrar periódicamente el trabajo de rama reciente main en ella. Esa estrategia ayuda a asegurarse de mantenerse al tanto del trabajo reciente de otros usuarios y resolver rápidamente los conflictos de combinación que surjan. Al rebasar, se implementa la nueva característica sobre el trabajo de rama más reciente main , lo que ayuda a mantener un historial de confirmaciones lineales.

Para obtener más información sobre la rebase de Git y cuándo usarlo, consulte Rebase frente a merge.

Directrices de rebase y de inserción forzada

Si vuelve a base de una rama local que ha insertado anteriormente y, a continuación, vuelve a ejecutar el comando de inserción de Git predeterminado, se producirá un error en la inserción. El comando de inserción de Git predeterminado aplica una combinación de avance rápido para integrar la rama local en la rama remota. Ese comando producirá un error después de una rebase porque la base modifica la secuencia de confirmaciones existentes en la rama de destino local, por lo que ya no coincide con el historial de su homólogo remoto. En este escenario, una inserción forzada se realizará correctamente; para ello, sobrescribirá la rama remota.

La rebase de Git y la inserción forzada son herramientas eficaces, pero tenga en cuenta estas directrices al decidir si se deben usar:

No vuelva a base de una rama local que se haya insertado y compartido con otros usuarios, a menos que esté seguro de que nadie use la rama compartida. Después de una rebase, la rama local ya no coincidirá con el historial de su homólogo remoto.
No forzar la inserción en una rama remota que usen otros usuarios, ya que su versión local de la rama remota ya no coincidirá con el historial de rama remota actualizado.
El equipo debe aceptar los escenarios de uso para la rebase y forzar la inserción.

Sugerencia

Para un proceso de revisión colaborativa, use una solicitud de incorporación de cambios para combinar un nuevo trabajo en la rama predeterminada de un repositorio remoto.

Cómo volver a base

Visual Studio 2022 proporciona una experiencia de control de versiones de Git mediante el menú Git , Cambios de Git y a través de menús contextuales en el Explorador de soluciones. La versión 16.8 de Visual Studio 2019 también ofrece la interfaz de usuario de Git de Team Explorer . Para obtener más información, consulte la pestaña Visual Studio 2019 - Team Explorer .

Elija Administrar ramas de Git > para abrir la ventana Repositorio de Git.
En la ventana Repositorio de Git , haga clic con el botón derecho en la rama de destino y seleccione Desproteger.
Haga clic con el botón derecho en la rama de origen y seleccione Rebase <target-branch en >source-branch<>.
Visual Studio mostrará un mensaje de confirmación después de una base correcta.

Si la rebase se detiene debido a conflictos de combinación, Visual Studio le notificará. Puede resolver los conflictos o cancelar la base de datos y volver al estado anterior a la base.

Para integrar confirmaciones de rama de origen en una rama de destino, ejecute el git rebase comando :

git rebase <source branch name> <target branch name>

Si la rama local actual es la rama de destino, puede simplificar el comando rebase para:

git rebase <source branch name>

Git le notificará si hay conflictos durante la rebase. Puede resolver los conflictos y, a continuación, ejecutar git rebase --continueo ejecutar git rebase --abort para deshacer la base de datos y volver al estado anterior a la base de datos.

Forzar la inserción de la rama local después de una rebase

Si vuelve a base de una rama local que ha insertado anteriormente, se producirá un error en una inserción predeterminada de Git posterior. En su lugar, puede forzar la inserción de la rama local para sobrescribir su homólogo remoto para que sus historiales de confirmación coincidan.

Advertencia

Nunca forzar la inserción de una rama en la que otros están trabajando. Para obtener más información, consulte Rebase y forzar instrucciones de inserción.

Para forzar la inserción en Visual Studio, primero debe habilitar la opción forzar inserción:

Vaya a Herramientas>Opciones de>control> de código fuenteconfiguración global de Git.
Seleccione la opción Habilitar inserción --force-with-lease .

La marca de inserción --force-with-lease de Git es más segura que la --force marca porque no sobrescribirá una rama remota que tenga confirmaciones que no están integradas dentro de la rama local que va a forzar la inserción.

En la ventana Cambios de Git , seleccione el botón de inserción para insertar la confirmación.

O bien, puede seleccionar Insertar en el menú Git .
Si se produce un error en la operación de inserción de Git predeterminada, Visual Studio inicia el cuadro de diálogo Git-Push con errores . Elija Forzar inserción.
Visual Studio mostrará un mensaje de confirmación después de una inserción correcta.

Sugerencia

Para forzar la inserción de nuevas confirmaciones desde la rama local en una rama remota con el mismo nombre:

git push --force-with-lease <remote> <local branch name>

Si la rama que desea insertar es la rama desprotegida, puede simplificar el comando force push para:

git push --force-with-lease <remote>

Al clonar un repositorio remoto, Git asigna el alias origin como abreviatura para la dirección URL del repositorio remoto que ha clonado. Ejecute git remote -v para comprobar el valor del origin alias. Para agregar el origin alias manualmente, ejecute git remote add origin <remote repo url>. Con el origin alias, puede simplificar aún más el comando force push:

git push --force-with-lease origin

Si la rama local actual realiza un seguimiento de una rama remota en origin, puede abreviar completamente el comando force push:

git push --force-with-lease

Sin embargo, se producirá un error en el comando de inserción totalmente abreviado si la rama local no realiza un seguimiento de una rama remota. Ejecute git remote show origin para comprobar el estado con seguimiento de las ramas.

Base interactiva para las confirmaciones locales de squash

Normalmente, a medida que trabaja en una nueva característica de la rama de características local, creará varias confirmaciones. Cuando esté listo para publicar la nueva característica, es posible que quiera consolidar esas confirmaciones en una sola confirmación para simplificar el historial de confirmaciones. Puede usar una base interactiva para aplastar varias confirmaciones en una sola confirmación.

Visual Studio 2022 no admite la reequilibración interactiva. Use la línea de comandos de Git en su lugar.

Consulte la rama local en la que desea realizar una base interactiva.
Confirme, guarde o descarte los cambios no confirmados.
Calcule lo lejos que desea ir en el historial de confirmaciones. No tiene que ser exacto, ya que tendrá que elegir confirmaciones específicas para squash al ejecutar el comando de rebase interactivo. Por ejemplo, si desea aplastar confirmaciones dentro de las cinco últimas confirmaciones, ejecute:
```
git rebase -i HEAD~5
```
Git abrirá un editor que enumera las cinco últimas confirmaciones, empezando por la más reciente. Por ejemplo:
```
pick 7068b09 Update README network switch section
pick 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
pick 00859d9 Add network controller test
```
Deje la primera línea tal como está. En las líneas posteriores, para combinar una confirmación con la anterior, cambie pick a squash. Por ejemplo, para combinar las dos confirmaciones principales y también las dos confirmaciones inferiores, modifique la lista de confirmaciones para:
```
pick 7068b09 Update README network switch section
squash 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
squash 00859d9 Add network controller test
```
Guarde y cierre el editor. Git abrirá un nuevo editor para cada conjunto de confirmaciones combinadas y le pedirá que escriba un mensaje de confirmación. Para cada conjunto de confirmaciones, comprima los mensajes de confirmación hasta un mensaje y, a continuación, guarde y cierre el editor. En el ejemplo anterior, las confirmaciones aplastadas se condensan con nuevos mensajes de confirmación:
```
8fcb88f Update README network sections
ac6d3c0 Fix fiber optic transmitter test
f0aadc3 Add two network tests
```
Aunque la confirmación Fix fiber optic transmitter test no se ha aplastado, tiene un nuevo identificador de confirmación porque ahora se vincula a otra confirmación predecesora.

Para más información sobre la rebasificación interactiva, consulte Modo interactivo de rebase de Git.

Nota:

Los usuarios de Azure DevOps pueden combinar para condensar el historial de confirmaciones de una rama de tema durante una solicitud de incorporación de cambios.

Pasos siguientes

Copia de los cambios con cherry-pick

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-12-17