Quelle est la différence entre «squash» et «fixup» dans l'extension Git / Git?

J'utilise les extensions Git depuis un moment maintenant (c'est génial!) Mais je n'ai pas trouvé de réponse simple à ce qui suit:

Parfois, lors de la saisie d'un message de validation, une faute de frappe. Mon ami m'a montré comment résoudre le problème de la manière suivante (dans Git Extentions):

Faites un clic droit sur le commit> Avancé> Commit de correction

Ensuite, je coche simplement la case "Modifier" et réécris mon message et le tour est joué! Mon message de validation est corrigé.

Cependant cette autre option "Squash commit" ... je me suis toujours demandé ce que ça faisait?!

Ma question est:

Quelqu'un pourrait -il simplement m'expliquer quelle est la différence exacte entre le commit Squash et le commit Fixup dans les extensions Git / Git ? Ils me semblent un peu ... "similaires" :

Je ne sais pas ce que Git Extensions en fait spécifiquement, mais il y git rebasea une option pour écraser ou réparer automatiquement les commits avec squash! ou réparation! préfixes, respectivement:

   --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 différence entre squash et fixup est que pendant le rebase, l' squashopération vous invitera à combiner les messages de l'original et du commit squash, tandis que l' fixupopération conservera le message d'origine et rejettera le message du commit de correction.

En termes simples, lors du rebasage d'une série de commits, chaque commit marqué comme un squash, vous donne la possibilité d'utiliser son message dans le cadre d'un message pickou de rewordcommit.

Lorsque vous utilisez fixuple message de cette validation est ignoré.

De git-rebase doc, section "mode interactif" :

Si vous voulez plier deux ou plusieurs commits en un seul, remplacez la commande "pick" pour le deuxième commits et les suivants par "squash" ou "fixup". Si les commits avaient des auteurs différents, le commit plié sera attribué à l'auteur du premier commit. Le message de commit suggéré pour le commit replié est la concaténation des messages de commit du premier commit et de ceux avec la commande "squash", mais omet les messages de commit des commits avec la commande "fixup".

Si la question est de savoir quelle est la différence entre squashet fixupdans git lors de l' exécution de git rebase --interactive , alors la réponse est le message de validation .

s, squash <commit> = utilise commit, mais fusionne avec le commit précédent

f, fixup <commit>= comme "squash", mais ignorez le message du journal de cette validation

Par exemple:

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

Le message de validation après le rebasage dans le cas 1 serait:

father commit message

child commit message

tandis que le message de validation dans le cas 2 est:

father commit message
# no sub messages

J'ai bricolé des extensions git et je n'ai pas réussi à écraser de nombreux commits en un seul. Pour ce faire, j'ai dû recourir à la ligne de commande et j'ai trouvé ce message utile

git rebase -i Head~2

Il s'agit d'un rebase interactif et notez ce qui suit:

• ~ 2 fait ici référence au nombre de commits que vous souhaitez impliquer dans cette opération, y compris la tête actuelle
• Vous devez éditer la fenêtre d'édition interactive suivante, laisser le premier élément comme "pick" et remplacer les lignes suivantes par "squash". Les instructions dans le lien ci-dessus sont beaucoup plus claires si elles sont opaques.

Pourquoi ne pas demander à git lui-même? Lorsque vous rebasez avec git-bash, il dit:

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

Donc tu vois:

s, squash = utilise commit, mais fusionne avec le commit précédent

f, fixup = comme "squash", mais ignorez le message du journal de cette validation