Resumen: Un debate frecuente en git es si usar rebase o fusionar.
1. ¿Es doloroso? El cordero perdido en la historia del código
Veamos primero una captura de pantalla gráfica del historial de envío de código real:
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
No sé cómo te sientes después de ver esta foto. ¿Es muy mudo? Me siento sin palabras y ahogado. El historial del código ha llegado a este punto, ¡es básicamente obsoleto! ! !
A través de este artículo hablaremos sobre el tema de la línea de historial de código. Esto implica un problema de gestión del historial de código. Si desea tener un historial de código más claro para poder rastrear rápidamente sus registros de código anteriores, debe prestar atención a este tema.
Si ha utilizado Mercurial como programador, es posible que ya comprenda este concepto de rebase. Actualmente, la herramienta de control de código fuente más utilizada por los programadores es git. Un argumento frecuente en git es si usar rebase o fusionar.
Decir que el argumento no es del todo exacto. Porque en el trabajo real, hay principalmente dos situaciones, una es que no sabe nada de rebase y la otra es que no sabe cómo usar rebase en absoluto.
Luego, hablemos de la diferencia entre rebase y merge. Funcionalmente, rebase traerá su trabajo de modificación actual a la vanguardia. Su orden de registro de modificación único no cambiará, pero el tiempo se basará principalmente en la marca de tiempo de la rama de destino actual. Ajustamiento.
Fusionar no cambia la marca de tiempo. Esto hará que diferentes personas fusionen sus registros de código modificado, habrá una situación de enclavamiento mutuo. El comienzo de este artículo es una captura de pantalla del historial de envío de código. El cableado interno es tan complicado como una placa de circuito.
Esta situación se produce principalmente porque los programadores se fusionan directamente sin rebase.
Y un historial de envío de códigos similar a una placa de circuito no tiene sentido porque es demasiado complicado. Casi no hay legibilidad. Si desea verificar algunos registros históricos, puede sumergirse rápidamente en este océano de información, incapaz de liberarse y eventualmente perderse y perderse.
2. Git Merge vs. rebase
Nota: Aunque se ha marcado en el enlace de referencia, es necesario destacar que la traducción de este apartado hace referencia al contenido en inglés del siguiente enlace:
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
El propósito de fusionar y rebase de Git es el mismo, ambos fusionan múltiples ramas en una. Aunque su objetivo final es el mismo, los dos métodos se implementan de diferentes maneras. Entonces, ¿cuál deberíamos usar?
Aquí tenemos un repositorio de muestra, que tiene dos ramas diferentes: la rama principal y la rama de características. Queremos combinarlos. Veamos cómo usar estos métodos para resolver este problema.
Imagen de https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/fc73a41ce658a6a566e2a54d60534ade/git-flow.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Unir
Cuando ejecuta git merge, su rama HEAD generará una nueva confirmación y conservará los antepasados de cada historial de confirmaciones.
Imagen de
https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/673b91456bdc6fd454c5ad203f825568/git-merge-2.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
La combinación de avance rápido es un tipo de combinación que no crea una confirmación y actualizará el puntero de la rama a la última confirmación.
Rebase
Rebase es reescribir la modificación de una rama a otra rama sin crear una nueva confirmación.
Cada confirmación que realice en la rama de funciones creará una nueva confirmación en la rama principal. Parece que estas confirmaciones siempre se han escrito en la rama maestra.
Imagen de https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/5ade4f7276bc6ad18dad4b6078950ac9/git-rebase.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Ventajas y desventajas de Merge
ventaja
- Fácil de usar y de entender.
- Mantenga el contexto original de la rama fuente.
- Las confirmaciones en la rama fuente son independientes de las confirmaciones de otras ramas.
- Puede mantener el historial de envíos.
Desventaja
- Caos
Imagen de https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Pros y contras de Rebase
ventaja
- El historial del código es simplificado, lineal y legible.
- En comparación con el historial de confirmaciones de muchas ramas de características independientes, es más fácil manipular un solo historial de confirmaciones.
- La información de envío limpia y clara puede rastrear mejor un error o cuándo se introdujo una función. Puede evitar numerosos envíos de una sola línea del historial de contaminación.
Desventaja
- El tiempo de envío histórico cambiará y es posible que se pierda el contexto.
Debe utilizar Rebase con más cuidado que Merge.
¿Debería usar Merge o Rebase?
Cuando su equipo no está familiarizado con rebase, git merge es la opción correcta para usted.
- Merge permite guardar el historial de confirmaciones de cualquier función dada sin preocuparse por sobrescribir las confirmaciones y cambiar el historial.
- Puede evitar la reversión o el reinicio de git innecesarios.
Por otro lado, si valora más el historial de código limpio y lineal, entonces git rebase es el más apropiado. De esta manera, puede evitar envíos innecesarios y mantener cambios más centrados y lineales.
Cabe señalar aquí que si reescribe el historial incorrectamente, puede causar serios problemas, así que asegúrese de saber lo que está haciendo cuando usa Rebase.
3. Un vaso de agua y un balde de agua
Permítanme hablar de la relación entre un vaso de agua y un balde de agua. Esta relación puede usarse para describir la situación en la que los profesores imparten conocimientos a los estudiantes. El significado principal es que si el maestro les da a los estudiantes un vaso de agua, el maestro debe tener un balde de agua.
De hecho, este principio también se aplica a nuestra industria de software.
Con respecto al enfoque de este artículo en el historial del código, lo que queremos mostrar al exterior es un historial de código claro y limpio. Para lograr este objetivo, necesitamos hacer mucho trabajo. Comparado con el historial del código limpio, este trabajo es la relación entre un balde de agua y un vaso de agua.
Esto es lo que solemos decir, sé cruel contigo mismo y haz que los demás se sientan más cómodos. Ser cruel con uno mismo no es solo una charla vacía, sino que en realidad se pregunta a sí mismo que se devana los sesos para pensar en cómo hacerlo bien. Póngase en la perspectiva del otro lado para ver nuestro resultado. Nos preguntamos si yo, como mantenedor y receptor de estos códigos, puedo aceptar un historial de códigos tan desordenado. La respuesta es, por supuesto, no.
Sabiendo esto, cuando estamos haciendo la gestión del historial de código, vale la pena sin importar lo difícil que sea.
Algunos programadores con muchos años de experiencia laboral pueden haber utilizado muchas herramientas de gestión de código, pero una de las operaciones que estas herramientas de gestión de código suelen utilizar es la fusión. Después de entrar en la era git, estos programadores también conservaron este hábito y se fusionaron directamente.
Hablé con algunos programadores y ni siquiera se dieron cuenta de que había una operación de rebase. Algunos sintieron que rebase era demasiado problemático y se dieron por vencidos después de usarlo varias veces.
Esta es la naturaleza absolutamente humana.
Cuando estamos acostumbrados a hacer las cosas de una manera, cuanto más lo hacemos, más seguro se siente, porque es efectivo y puede resolver problemas. Cuando hay otra forma mejor, pero es muy diferente a la anterior, tendremos un rechazo instintivo. Esto se debe a nuestro miedo a lo desconocido.
Después de dejar la zona de confort, la mayoría de nosotros nos sentiremos incómodos y algunos incluso tendrán una fuerte sensación de pérdida.
Pero cuando regresemos a nuestro corazón, encontraremos que todo lo que hemos dado y el dolor que soportamos vale la pena. Porque nuestra intención original es satisfacer a los usuarios. Los usuarios del historial del código son programadores como nosotros.
4. ¿Cómo hacer un rebase correctamente?
Notas importantes:
Hay varios puntos clave relacionados con Rebase:
- Rebase en su propia rama;
- Para reajustar la rama de destino correcta, tenga en cuenta que esta rama de destino no es su rama remota, a menudo hay errores en este lugar;
- El rebase debe realizarse con frecuencia para evitar conflictos o aumentar la dificultad de los conflictos;
- Antes de incorporar el código, debe hacer una Rebase y luego Fusionar una última vez;
- Es mejor usar Squash Merge para agregar el mensaje de confirmación correcto;
- No rebase en la rama principal;
- Trate de no forzar el empuje;
¿Debe rebase en la rama maestra? ¿Cómo hacer rebase?
Primero que nada, quiero enfatizar que no rebase en la rama principal. Esto se debe a que si realiza un rebase en la rama maestra, si presiona por primera vez, puede que no haya ningún problema, pero si alguien más también hace un rebase, esto dará como resultado dos cabezas diferentes en su rama maestra. En este momento, si desea presionar nuevamente, habrá un problema.
Si todo es controlable, puede forzar el empuje de forma muy brusca. Sin embargo, si hay más miembros del equipo, esta operación eliminará otras presentaciones que ya han llegado.
A menos que sea absolutamente necesario, no debemos rebasar en la rama principal.
A continuación, hablemos de un escenario en el que rebase se usa correctamente. Después de recibir una tarea, crearemos una nueva rama en la confirmación en el último nodo de la rama principal. En la nueva rama, continuaremos realizando nuevas confirmaciones hasta que se complete la tarea de la rama.
En este momento, queremos crear una solicitud de fusión o una solicitud de extracción. Antes de eso, lo primero que debemos hacer es rebase. La rama de destino seleccionada por rebase es nuestra rama maestra.
Después de completar esta operación de rebase, podemos crear mr o pr. Puede haber muchas revisiones durante el proceso de revisión. Una vez completada la revisión, debe
volver a establecer la base y luego presionar. Repetido esto varias veces, mr o pr aprobado. En este punto, haremos una combinación de squash para empaquetar varias confirmaciones en una en la rama principal.
Lo anterior es una descripción y explicación de un caso realista de cómo usar rebase en el proceso de trabajo normal. Espero que puedas experimentarlo y contarme tu experiencia. Por favor, deja un mensaje y cuéntame lo que piensas.
referencias
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
https://www.perforce.com/blog/vcs/git-rebase-vs-merge-which-better
https: // product.hubspot.com/blog/git-and-github-tutorial-for-beginners
https://git-scm.com/docs/gittutorial
Haga clic para seguir y conocer la nueva tecnología de Huawei Cloud por primera vez ~