origin - git merge--abort
¿Por qué git se confirma después de una fusión de forma predeterminada? (1)
Tengo curiosidad por este comportamiento y tal vez solo porque vengo de usar SVN y Bazaar principalmente. (Estoy aprendiendo git para interactuar con el excelente github.)
Me parece contrario a lo intuitivo y como si fuera mejor para
git merge [branch] --no-commit
ser el predeterminado para alentar a las personas a asegurarse de que la fusión fuera como lo deseaban antes de comprometerse.
El objetivo establecido por Linus Torvalds al crear Git fue hacer todas las combinaciones que podrían resolverse automáticamente ... RÁPIDO . Ver su Google Tech Talk 2007: Linus Torvalds en Git (transcripción)
Es decir, cientos de fusiones en menos de unos segundos.
Por lo tanto, un " --no-commit " por defecto prácticamente anularía ese propósito.
Con
--no-commitrealice la fusión pero simule que la fusión falló y no se vuelva a enviar automáticamente, para que el usuario tenga la oportunidad de inspeccionar y ajustar aún más el resultado de la fusión antes de cometer.
Extracto de la charla de Linus (video) :
Lo único que importa es qué tan rápido puedes fusionar .
En git, puedes fusionar ... Combino 22,000 archivos varias veces al día, y me siento infeliz si una fusión demora más de 5 segundos, y todos esos 5 segundos son solo descargas de todos los diffs, bueno no los diffs sino sus Los deltas entre dos árboles, la fusión en sí toma menos de medio segundo.
Y no tengo que pensarlo.
[...] Ese es el tipo de rendimiento que realmente cambia la forma en que trabajas.