¡Deja de usar Merge y abraza felizmente a Rebase!

1. Introducción

Hola a todos, soy Bittao. Como la herramienta de administración de versiones más popular, Git debe ser utilizado por todos en el proceso de desarrollo. Dado que Merge realiza muchas operaciones en Git de forma predeterminada, y es relativamente menos propenso a errores, muchas personas usarán Merge para fusionar código. Sin embargo, como uno de los comandos principales en Git, Rebase aún debe entenderse y usarse en escenarios adecuados.

2. El papel de Rebase

Rebase traducción china: 变基Creo que esta traducción es bastante contundente, lo que hace que muchas personas no entiendan completamente el significado de rebase. Personalmente, me refiero a Rebase 认爸爸, por ejemplo, puede rebase a la rama de Papa Ma y convertirse en su heredero razonable.

La imagen de arriba muestra una situación de reorganización. Puede ver el efecto final como si la rama Característica no existiera, y la Confirmación recién enviada parece que realmente se envió en la rama principal. Y si usamos Merge, se generará un nodo de combinación:

puede que no sea nada ver el nodo Commit generado por una sola combinación, pero en proyectos reales, existe una alta probabilidad de que se vuelva así: es

un lote desordenado , como si viera el nodo Commit hace muchos años Un montón de código escrito por otras personas, ¡qué, qué, qué es! Por el contrario, mira proyectos reales desarrollados con Rebase. No hay daño sin comparación:

Es por eso que You Yuxi también recomienda usar rebase:

3. Cómo usar Rebase

De hecho, muchas personas no usan Rebase, por un lado, no entienden cómo usarlo en la colaboración real del proyecto. Por otro lado, lo he usado, pero hay muchos problemas, por lo que pienso erróneamente que no es fácil de usar y nunca lo volveré a usar. Permítanme compartir aquí, el proceso colaborativo de Rebase que adopté recientemente cuando trabajaba en un proyecto (a modo de ilustración, se ha simplificado adecuadamente):

3.1 Pago

En primer lugar, si queremos desarrollar nuevas funciones o corregir errores de la rama maestra, debemos verificar una rama. Por ejemplo,
revisa la rama dev en el nodo A, para hacer la escena más complicada, después de git checkout dev la rama. Algunas personas continuaron enviando B y C en el maestro, formando la siguiente estructura de Git:

Quiero enfatizar aquí que muchas personas tienen problemas con rebase porque quieren que la rama sea rebase para ser una rama pública. De hecho, el desarrollador aquí solo debería ser adecuado para la rama que usa.Recuerde que Git en sí mismo es una administración de versiones distribuidas. De hecho, el control de versiones se puede realizar muy bien sin almacenes remotos.Necesitamos distinguir los conceptos de sucursales locales y sucursales remotas, que no están directamente relacionados. Así que puedes hacer una rama NB en tu máquina local.Después de la reorganización, nadie sabrá qué nombre fantasma te diste.

3.2 Gestión remota

Si nuestra propia rama de desarrollo no se desarrolla necesariamente en una computadora, para desarrollarla en varias computadoras nosotros mismos, podemos asociar un almacén remoto propio. Este paso es opcional.

3.3 Comenzar a reorganizar

Ahora hemos desarrollado D y E en dev, y luego dev rebase masterformado A, B, C, D, E:

aunque parece ser una línea recta aquí, de hecho, solo dev sabe que su padre se ha convertido en maestro, pero el maestro no lo reconoce. este hijo Entonces también necesitamos: master merge dev, para que se forme una línea recta perfecta en el maestro:

Finalmente, vaya git push origin mastera la rama remota para completar este desarrollo.

3.4 Cuidado posterior

Después de rebase, dev ha cambiado su base, lo que equivale a reconocer al ladrón como el padre, ¿y ahora quieres reconocerlo de nuevo? ¡No lo pienses! Por lo tanto, solo se puede resolver por la fuerza, forzando el envío a su propio almacén remoto en la sucursal no protegida: git push --force origin devy, finalmente, rebase dev a su propia sucursal remota: git rebase origin devpara facilitar el mantenimiento de su propio almacén remoto. Hasta ahora, el desarrollo en forma de rebase se ha completado y se puede continuar con el próximo desarrollo.

4. Ventajas y desventajas de Rebase

Permítanme hablar sobre las ventajas primero:

• Mantenga el historial de confirmación lineal: al fusionar ramas con merge, se crea una nueva confirmación de fusión, formando así una nueva rama en el historial de confirmación. Con rebase, el registro de confirmación se puede agregar directamente al final de la rama de destino, manteniendo así la linealidad del historial de confirmación.
• Reduzca los envíos de combinación innecesarios: al usar la combinación para combinar ramas, se creará un nuevo envío de combinación, que puede contener mucha información de combinación sin sentido. Con rebase, los registros de confirmación se pueden agregar al final de la rama de destino uno por uno, evitando la creación de confirmaciones de combinación innecesarias.
• Mejor revisión y trazabilidad del código: con rebase, el historial de confirmaciones se puede hacer más intuitivo y comprensible, lo que facilita la revisión del código y la trazabilidad de los problemas.
• Evite conflictos: al fusionar ramas, la fusión puede fallar debido a conflictos entre las dos ramas. Con rebase, estos conflictos se pueden resolver antes de rebase, evitando así conflictos durante la fusión.

En resumen, aunque rebase no es una solución universal para todas las situaciones, en la mayoría de los casos, usar rebase puede ayudarnos a crear un historial de confirmaciones más limpio e intuitivo y mejorar la eficiencia de la colaboración en equipo.

Habiendo dicho eso, parece estar hablando de las ventajas de Rebase, entonces, ¿Rebase no tiene desventajas? Por supuesto que no, de lo contrario todos habrían cambiado de Merge a Rebase hace mucho tiempo. Desventajas de Rebase:

• Resolver conflictos es engorroso. Los conflictos de rebase se comparan por confirmación, y los conflictos de fusión se comparan en función del resultado final. Si usa rebase, es mejor fusionar el código con frecuencia. De lo contrario, si rebase en el Al final del desarrollo a largo plazo, realmente será un problema. Resuelva el conflicto hasta que la gente sea estúpida.
• No hay un registro de combinación, pero Merge tiene un registro, por lo que si hay un problema, se puede resolver fácilmente.
• Los pasos de operación son relativamente engorrosos.

5. Conclusión

El problema central del desarrollo colaborativo es en realidad la fusión. Cómo fusionarse de manera razonable y elegante es un problema que todo equipo debe considerar. Como los comandos principales en Git, Merge y Rebase en realidad tienen sus propias ventajas, y es muy común usarlos juntos. De acuerdo con su propio equipo y la situación del proyecto, es mejor elegir el método apropiado. Finalmente, les deseo todo lo mejor en la fusión de código ~