Cómo git cherry-pick y revert usan una fusión de 3 vías

Artículo original ↗ Discusión en Hacker News ↗

Los comandos cherry-pick y revert de Git revelan que usan fusiones completas de 3 vías internamente, lo que explica por qué a menudo se comportan de forma más robusta que la simple aplicación de parches. A partir de ahí, los desarrolladores debaten flujos de trabajo y modelos mentales más amplios de Git —especialmente merge vs. rebase, squash merges y desarrollo basado en trunk— y cómo estas decisiones afectan la claridad del historial, la frecuencia de conflictos y la productividad del equipo. Muchos sostienen que el poder de Git justifica su complejidad, pero enfatizan que unas buenas herramientas, tutoriales y la comprensión de la estructura de grafo subyacente de Git son clave para evitar errores dolorosos.

Reacción general al artículo

  • Muchos encontraron esclarecedora la explicación de cherry-pick/revert usando una fusión de 3 vías; confirmó la intuición de que estas operaciones son “más inteligentes que un parche plano”.
  • A algunos les sorprendió que cherry-pick esté implementado como una fusión de 3 vías y que rebase sea, en esencia, una secuencia de cherry-picks.
  • Unos pocos señalaron detalles menores, por ejemplo, enlazar a la rama master en lugar de hashes de commit específicos para mayor estabilidad a largo plazo.

Complejidad de Git, modelos mentales y UX

  • Varios comentarios se quejan de que Git parece excesivamente complejo, especialmente al corregir el historial o resolver errores de otros.
  • Otros sostienen que esa potencia/complejidad es necesaria para equipos grandes y distribuidos, y que los problemas suelen venir de modelos mentales débiles.
  • Varias personas subrayan que hay que entender el modelo subyacente de grafo/snapshots de Git (commits como árboles completos, no parches) en lugar de memorizar comandos.
  • Las UIs visuales y los tutoriales buenos (vistas de grafo, herramientas de conflictos, sitios como learngitbranching y documentación estilo “plumber’s guide”) se consideran de gran ayuda.

Merge vs rebase vs squash: filosofías en competencia

  • Hay una fuerte división entre los defensores de “siempre merge” y los de “rebase para un historial lineal”.
  • Defensores de merge:
    • Prefieren commits de merge explícitos, sin rebase (o con rebase raro), y a menudo convierten las ramas de funcionalidad en un solo commit mediante squash.
    • Argumentan que los merges son conceptualmente más simples, los conflictos son más fáciles y hacer rebase de ramas compartidas es peligroso.
  • Defensores de rebase:
    • Hacen rebase con frecuencia en ramas locales/de tema para mantener un historial lineal y fácil de bisecar; usan rebase interactivo para crear commits limpios y atómicos.
    • Ven los squash merges como una forma de ocultar un desarrollo desordenado y reducir el valor del historial.
  • Algunos señalan compromisos prácticos: las ramas de larga duración hacen que el rebase sea doloroso (conflictos repetidos), mientras que los historiales sucios de ramas de funcionalidad hacen que los merges sin squash sean ruidosos.

Flujos de trabajo y prácticas de equipo

  • Se elogia el desarrollo basado en trunk con ramas de vida corta y feature flags, especialmente para SaaS.
  • Otros usan subconjuntos muy mínimos de comandos y evitan funciones avanzadas para no meterse en problemas.
  • Hay desacuerdo sobre cuánta estructura necesitan realmente los equipos pequeños frente a procesos sobrecomplicados por “seguridad”.

Notas técnicas sobre fusión de 3 vías y conflictos

  • Varios destacan merge.conflictStyle=diff3 / zdiff3 y las herramientas visuales de 3 vías como ayudas importantes para resolver conflictos.
  • La discusión aclara que la fusión de 3 vías precede a Git y no es asociativa, lo que puede producir comportamientos sorprendentes; algunos especulan sobre esquemas de fusión más ricos (por ejemplo, contextos de “cuatro vías”).
  • Cherry-pick y rebase se presentan como formas de aplicar diffs usando fusión de 3 vías, lo que puede funcionar donde parches ingenuos al estilo git apply fallarían.