¿Cuáles son las ventajas de una rebase sobre una fusión en git?

En este artículo , el autor explica el rebase con este diagtwig:

text alternativo http://eagain.net/articles/git-for-computer-scientists/git-history.7.png

Rebase: si aún no ha publicado su sucursal, o ha comunicado claramente que los demás no deberían basar su trabajo en ella, tiene una alternativa. Puede volver a establecer la base de su bifurcación, donde en lugar de fusionarse, su confirmación se sustituye por otra confirmación con un elemento primario diferente, y su bifurcación se mueve allí.

mientras que una combinación normal se habría visto así:

text alternativo http://eagain.net/articles/git-for-computer-scientists/git-history.5.png

Entonces, si rebase , simplemente está perdiendo un estado de historial (que sería basura recolectada en algún momento en el futuro). Entonces, ¿por qué alguien querría hacer una rebase en absoluto? ¿Que me estoy perdiendo aqui?

Hay una variedad de situaciones en las que es posible que desee volver a establecer la base.

  • Desarrolla algunas partes de una característica en twigs separadas, luego se da count de que en realidad son una progresión lineal de ideas. Vuelva a ponerlos en esa configuration.

  • Bifurca un tema del lugar equivocado. Tal vez sea demasiado temprano (necesita algo más adelante), tal vez sea demasiado tarde (en realidad también se aplica a versiones anteriores). Moverlo al lugar correcto. El caso "demasiado tarde" en realidad no puede ser arreglado por una fusión, por lo que rebase es crítico.

  • Desea probar la interacción de una twig con otra twig, pero por alguna razón no desea fusionarse. Por ejemplo, es posible que desee ver qué conflictos surgen commit-by-commit, en lugar de todos a la vez.

El tema general aquí es que la combinación excesiva complica la historia, y el rebase es una forma de evitarla si no conseguiste tu plan de combinación / bifurcación al principio. Demasiadas fusiones pueden hacer que sea difícil para un humano seguir la historia, y también puede dificultar el uso de herramientas como git-bisect .

También hay muchos casos que provocan una rebase interactiva:

  • Las confirmaciones múltiples deberían haber sido una confirmación.

  • Una confirmación (no la actual) debería haber sido varias confirmaciones.

  • Una confirmación (no la actual) tuvo un error en ella o en su post.

  • Se debe eliminar una confirmación (no la actual).

  • Los compromisos deben reorderarse (por ejemplo, para fluir más lógicamente).

Si bien es cierto que "pierdes historia" haciendo estas cosas, la realidad es que solo quieres publicar trabajos limpios. Si todavía hay algo inédito, está bien volver a establecer la base para transformarlo de la forma en que debería haberlo cometido. Esto significa que la versión final en el repository público será lógica y fácil de seguir, sin preservar ninguno de los inconvenientes que tuvo un desarrollador en el path.

Rebasing le permite recoger fusiones en el order correcto. La teoría detrás de la fusión significa que no deberías preocuparte por eso. La realidad de resolver conflictos complicados se vuelve más fácil si rebase, luego fusiona nuevos cambios en order.

Es posible que desee leer sobre Bunny Hopping