Articles

por qué deberías dejar de usar Git rebase

Posted by admin

después de usar Git durante varios años, me encontré usando gradualmente más y más comandos git avanzados como parte de mi flujo de trabajo diario. Poco después de descubrir Git rebase, lo incorporé rápidamente a mi flujo de trabajo diario. Aquellos que están familiarizados con el rebase saben lo poderosa que es una herramienta y lo tentador que es usarla todo el tiempo. Sin embargo, pronto descubrí que el rebase presenta algunos desafíos que no son obvios cuando empiezas a hacerlo. Antes de presentarlos, resumiré rápidamente las diferencias entre la fusión y el cambio de base.,

primero consideremos el ejemplo básico donde desea integrar una rama de características con master. Al fusionar, creamos un nuevo commit g que representa la fusión entre las dos ramas. El gráfico commit muestra claramente lo que ha sucedido, y podemos ver los contornos del gráfico «train track» familiar de Git-repos más grandes.,

Example of merging

Alternatively, we could rebase before merging. The commits are removed and the feature branch is reset to master, after which the commits are re-applied on top of feature., Las diferencias de estas confirmaciones reaplicadas son generalmente idénticas a sus contrapartes originales, pero tienen diferentes confirmaciones padre, y por lo tanto diferentes claves SHA-1.

Ejemplo de reajuste

Ahora hemos cambiado la base de la confirmación de feature de b a c, literalmente, volver a basarlo., Merging feature to masteris now a fast-forward merge, because all commits on feature are direct descendants of master.

Example of fast-forward merging

Compared to the merge approach, the resulting history is linear with no divergent branches., La legibilidad mejorada fue la razón por la que solía preferir rebasar ramas antes de fusionarlas, y espero que este sea el caso para otros desarrolladores también.

sin embargo, este enfoque tiene algunos desafíos que pueden no ser obvios.

Considere el caso donde una dependencia que aún está en uso en feature ha sido eliminado en master. Cuando feature se está rebasando en master, la primera confirmación reaplicada romperá su compilación, pero mientras no haya conflictos de fusión, el proceso de rebase continuará ininterrumpido., El error de la primera confirmación permanecerá presente en todas las confirmaciones posteriores, resultando en una cadena de confirmaciones rotas.

este error solo se descubre después de finalizar el proceso de rebase, y generalmente se corrige aplicando una nueva confirmación de corrección de error g en la parte superior.,

Ejemplo de error de reajuste

Si usted consigue conflictos durante reajuste sin embargo, Git pausa en el conflicto de cometer, permitir que usted para solucionar el conflicto antes de continuar. Resolver conflictos en medio de una larga cadena de commits es a menudo confuso, difícil de hacer bien, y otra fuente de posibles errores.

introducir errores es un problema adicional cuando ocurre durante el cambio de base., De esta manera, se introducen nuevos errores cuando se reescribe la historia, y pueden disfrazar errores genuinos que se introdujeron cuando se escribió la historia por primera vez. En particular, esto hará que sea más difícil usar git bisect, posiblemente la herramienta de depuración más poderosa en la caja de herramientas de Git. Como ejemplo, considere la siguiente rama de características. Digamos que hemos introducido un error hacia el final de la rama.,

Una rama con errores introducidos hacia el final

Usted no puede descubrir este error hasta que semanas después de que la rama se fusionó a master. Para encontrar la confirmación que introdujo el error, es posible que tenga que buscar entre decenas o cientos de confirmaciones., Este proceso se puede automatizar escribiendo un script que pruebe la presencia del error y ejecutándolo automáticamente a través de Git bisect, utilizando el comando git bisect run <yourtest.sh>.

Bisect realizará una búsqueda de bisección a través del historial, identificando la confirmación que introdujo el error. En el ejemplo que se muestra a continuación, tiene éxito en encontrar la primera confirmación defectuosa, ya que todas las confirmaciones rotas contienen el error real que estamos buscando.,

Example of successfull Git bisect

On the other hand, if we’ve introduced additional broken commits during rebasing (here, d and e), bisect will run into trouble., En este caso, esperamos que Git identifique commit f como el malo, pero identifica erróneamente den su lugar, ya que contiene algún otro error que rompe la prueba.

Ejemplo de un error de Git bisecar

Este problema es mayor de lo que puede parecer en un principio.

¿Por qué usamos Git?, Porque es nuestra herramienta más importante para rastrear la fuente de errores en nuestro código. Git es nuestra red de seguridad. Al rebasar, damos a esto menos prioridad, en favor del deseo de lograr una historia lineal.

hace un tiempo, tuve que pasar por varios cientos de confirmaciones para rastrear un error en nuestro sistema. El commit defectuoso se encontraba en medio de una larga cadena de commits que no se compilaron, debido a un rebase defectuoso que un colega había realizado. Este error innecesario y totalmente evitable resultó en que gastara casi un día extra en rastrear el commit.,

Entonces, ¿cómo podemos evitar estas cadenas rotas cometa durante reajuste? Un enfoque podría ser dejar que el proceso de rebase termine, probar el código para identificar cualquier error, y volver a la historia para corregir los errores donde se introdujeron. Con este fin, podríamos usar el rebase interactivo.

otro enfoque sería hacer que Git haga una pausa durante cada paso del proceso de rebase, pruebe si hay errores y corríjalos inmediatamente antes de Continuar.

Este es un proceso engorroso y propenso a errores, y la única razón para hacerlo sería lograr una historia lineal. ¿Hay una manera más simple y mejor?,

existe; git merge. Es un proceso simple, de un solo paso, donde todos los conflictos se resuelven en un solo commit. La confirmación de fusión resultante marca claramente el punto de integración entre nuestras ramas, y nuestra historia describe lo que realmente sucedió y cuándo sucedió.

la importancia de mantener su historia verdadera no debe subestimarse. Al cambiar de base, te estás mintiendo a ti mismo y a tu equipo. Pretendes que las confirmaciones fueron escritas hoy, Cuando de hecho fueron escritas ayer, basado en otra confirmación., Has sacado los commits de su contexto original, disfrazando lo que realmente sucedió. ¿Puedes estar seguro de que el código se construye? ¿Puedes estar seguro de que los mensajes de confirmación siguen teniendo sentido? Usted puede creer que usted está limpiando y aclarando su historia, pero el resultado puede muy bien ser lo contrario.

Es imposible decir qué errores y desafíos trae el futuro para su base de código. Sin embargo, puede estar seguro de que una historia verdadera será más útil que una reescrita (o falsa).

Leave A Comment