A menudo, los desarrolladores pueden elegir entre Fusionar (fusionar) y Rebase (reubicación). En Google verá una opinión diferente, se recomienda a muchos que no utilicen Rebase, ya que esto puede causar serios problemas. En el artículo, explicaré qué son las fusiones y movimientos, por qué debería (o no) usarlos y cómo hacerlo.
Git Merge y Git Rebase comparten el mismo objetivo. Están diseñados para integrar cambios de una rama a otra. Aunque el objetivo final es el mismo, los principios de operación son diferentes.
Algunas personas piensan que siempre debes usar Rebase; otras prefieren Fusionar. Esto tiene sus pros y sus contras.
Git merge
La fusión es una práctica común para los desarrolladores que usan sistemas de control de versiones. Independientemente de si las ramas se crean para pruebas, corrección de errores u otras razones, la fusión captura los cambios en otros lugares. La fusión toma el contenido de la rama de origen y los combina con la rama de destino. En este proceso, solo se cambia la rama de destino. La historia de las ramas de origen permanece sin cambios.
Pros:- simplicidad
- conserva la historia completa y el orden cronológico;
- mantiene un contexto de rama.
Contras:- la historia de los commits se puede completar (contaminar) con muchos commits;
- La depuración con git bisect puede ser más complicada.
Como hacerloCombine la rama maestra en la rama característica utilizando los comandos de
pago y
fusión .
$ git checkout feature $ git merge master (or) $ git merge master feature
Esto creará un nuevo "Compromiso de fusión" en la rama de características, que contiene un historial de ambas ramas.
Git rebase
Rebase es otra forma de impulsar los cambios de una rama a otra. Rebase comprime todos los cambios en un solo parche. Luego integra el parche en la rama de destino.
A diferencia de la fusión, el movimiento sobrescribe el historial porque transfiere el trabajo completado de una rama a otra. El proceso elimina la historia no deseada.
Pros:- Simplifica una historia potencialmente compleja.
- Simplificación de manipulaciones con un solo commit
- Evitar la fusión de confirmaciones en repositorios ocupados y sucursales
- Limpia las confirmaciones intermedias, convirtiéndolas en una única confirmación, que es útil para los comandos DevOps
Contras:- La compresión de funciones en algunas confirmaciones puede ocultar el contexto
- Mover repositorios públicos puede ser peligroso cuando se trabaja en equipo.
- Más trabajo aparece
- Para la recuperación con ramas eliminadas, se requiere una inserción. Esto lleva a una actualización de todas las ramas que tienen el mismo nombre, tanto local como remotamente, y esto es terrible.
Si haces el movimiento incorrectamente, la historia cambiará, y esto puede conducir a problemas serios, ¡así que asegúrate de hacerlo!
Como hacerloMueva la rama característica a la rama principal usando los siguientes comandos.
$ git checkout feature $ git rebase master
Esto mueve toda la rama de función a la rama principal. El historial del proyecto está cambiando, se crean nuevas confirmaciones para cada confirmación en la rama principal.
Movimiento interactivo
Esto le permite cambiar las confirmaciones cuando se mueven a una nueva rama. Esto es mejor que el movimiento automático porque proporciona control total sobre el historial de confirmaciones. Normalmente se usa para borrar el historial antes de fusionar la rama de características en maestra.
$ git checkout feature $ git rebase -i master
Esto abrirá el editor, enumerando todas las confirmaciones que se moverán.
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3
Esto determina exactamente cómo se verá la rama después de moverse. Al organizar los objetos, puedes hacer la historia como quieras. Puede usar los comandos de
reparación ,
squash ,
edición , etc.
¿Cuál usar?
Entonces, ¿qué es mejor? ¿Qué recomiendan los expertos?Es difícil tomar la única decisión correcta sobre cuál es mejor usar, ya que todos los equipos son diferentes. Todo depende de las necesidades y tradiciones del equipo.
Tomar decisiones basadas en la competencia del equipo en Git. ¿Es importante para usted la simplicidad o la reescritura de la historia, o tal vez algo más?
Que recomiendo?A medida que el equipo crece, se hace difícil administrar o rastrear los cambios de desarrollo mediante una fusión. Para tener un historial de confirmación limpio y comprensible, es aconsejable utilizar Rebase.
Beneficios de Rebase:- Te desarrollas localmente: si no has compartido tu trabajo con nadie más. Por ahora, debería preferir mover la fusión para mantener su historia en orden. Si tiene una bifurcación de repositorio personal que no se comparte con otros desarrolladores, puede cambiar la base de expresión incluso después de mudarse a su sucursal.
- Su código está listo para su revisión: ha creado una solicitud de extracción. Otros analizan su trabajo y potencialmente lo ponen en su lugar para una revisión local. Por el momento, no debes mover tu trabajo. Debe crear una confirmación de "rehacer" y actualizar la rama. Esto ayuda a realizar un seguimiento de las solicitudes de solicitudes de extracción y evita la ruptura accidental de la historia.
- La revisión está lista y lista para integrarse en la rama objetivo. Felicidades Está a punto de eliminar su rama de características. Dado que de ahora en adelante, otros desarrolladores no buscarán fusionar estos cambios, esta es su oportunidad de cambiar su historia. En este punto, puede volver a escribir el historial y restablecer las confirmaciones originales, y estas molestas "alteraciones" y "fusiones" se fusionan en un pequeño conjunto de confirmaciones específicas. Crear una fusión explícita para estas confirmaciones es opcional, pero es importante. Registra cuando la función ha alcanzado el maestro.
Ahora ya sabes, aunque insignificante, pero la diferencia entre Merge y Rebase. Estoy seguro de que tomará la decisión correcta y utilizará lo que sea adecuado para usted.
No te olvides: code = coffee + developer