¿Cuál es la diferencia entre "squash" y "fixup" en Git / Git Extension?

He estado usando Git Extensions por un tiempo (¡es increíble!) Pero no he encontrado una respuesta simple a lo siguiente:

A veces, al escribir un mensaje de confirmación, comete un error tipográfico. Mi amigo me mostró cómo solucionarlo de la siguiente manera (en Extensiones de Git):

Haga clic con el botón derecho en el compromiso> Avanzado> Confirmación de reparación

Entonces simplemente marco la casilla "Modificar" y reescribo mi mensaje y ¡listo! Mi mensaje de confirmación está arreglado.

Sin embargo, esta otra opción "Squash commit" ... ¡¿Siempre me he preguntado qué hace ?!

Mi pregunta es:

¿Alguien podría simplemente explicarme cuál es la diferencia exacta entre Squash commit y Fixup commit en Git / Git Extentions ? Se ven un poco ... "similares" a mí:

No sé qué hace Git Extensions con él específicamente, ¡pero git rebasetiene una opción para aplastar o arreglar confirmaciones automáticamente con aplastar! o reparación! prefijos, respectivamente:

   --autosquash, --no-autosquash
       When the commit log message begins with "squash! ..." (or "fixup!
       ..."), and there is a commit whose title begins with the same ...,
       automatically modify the todo list of rebase -i so that the commit
       marked for squashing comes right after the commit to be modified,
       and change the action of the moved commit from pick to squash (or
       fixup).

La diferencia entre squash y fixup es que durante el rebase, la squashoperación le pedirá que combine los mensajes del original y el squash commit, mientras que la fixupoperación mantendrá el mensaje original y descartará el mensaje del fixup commit.

En pocas palabras, al reajustar una serie de confirmaciones, cada confirmación marcada como squash, le da la oportunidad de usar su mensaje como parte de un mensaje de confirmación picko rewordconfirmación.

Cuando utiliza fixupel mensaje de esa confirmación se descarta.

Desde git-rebase doc, sección "modo interactivo" :

Si desea plegar dos o más confirmaciones en una, reemplace el comando "seleccionar" para la segunda confirmación y las subsiguientes por "aplastar" o "arreglar". Si las confirmaciones tenían diferentes autores, la confirmación doblada se atribuirá al autor de la primera confirmación. El mensaje de confirmación sugerido para la confirmación plegada es la concatenación de los mensajes de confirmación de la primera confirmación y de aquellos con el comando "squash", pero omite los mensajes de confirmación de las confirmaciones con el comando "fixup".

Si la pregunta es cuál es la diferencia entre squashy fixupen git al hacer git rebase --interactive , entonces la respuesta es el mensaje de confirmación .

s, squash <commit> = usar la confirmación, pero fusionar con la confirmación anterior

f, fixup <commit>= como "squash", pero descarta el mensaje de registro de esta confirmación

Por ejemplo:

pick 22a4667 father commit message
squash 46d7c0d child commit message # case 1
# fixup 46d7c0d child commit message # case 2

El mensaje de confirmación después de rebasar en el caso 1 sería:

father commit message

child commit message

mientras que el mensaje de confirmación en el caso 2 es:

father commit message
# no sub messages

Jugué con las extensiones de git y no pude hacer que aplastara muchas confirmaciones en una. Para hacer eso, tuve que recurrir a la línea de comando y encontré esta publicación útil

git rebase -i Head~2

Esta es una rebase interactiva y tenga en cuenta lo siguiente:

• ~ 2 aquí se refiere a la cantidad de confirmaciones que desea involucrar en esta operación, incluido el encabezado actual
• Tienes que editar la ventana de edición interactiva subsiguiente, dejar el primer elemento como "seleccionar" y reemplazar las líneas subsiguientes con "aplastar". Las instrucciones del enlace anterior son mucho más claras si es opaco.

¿Por qué no preguntarle a Git? Cuando rebasas con git-bash, dice:

pick 512b1d7 (some comment)
# Rebase 621b2e4..512b1d7 onto 621b2e4 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
D:/code/fenixito-legacy-api/.git/rebase-merge/git-rebase-todo [unix] (11:57 23/10/2019)                                         1,1 start
"D:/code/xxx/.git/rebase-merge/git-rebase-todo" [UNIX] 27L, 1170C

Como puedes ver:

s, squash = use commit, pero se fusiona con el compromiso anterior

f, fixup = like "squash", pero descarta el mensaje de registro de esta confirmación