Jaka jest różnica między „squash” a „fixup” w rozszerzeniu Git / Git?

Od jakiegoś czasu używam Git Extensions (jest niesamowity!), Ale nie znalazłem prostej odpowiedzi na następujące pytania:

Czasami podczas wpisywania komunikatu o zatwierdzeniu popełnia się literówkę. Mój przyjaciel pokazał mi, jak to naprawić w następujący sposób (w rozszerzeniach Git):

Kliknij prawym przyciskiem myszy zatwierdzenie> Zaawansowane> Zatwierdzenie poprawek

Następnie po prostu zaznaczam pole „Popraw”, przepisuję swoją wiadomość i voila! Moja wiadomość dotycząca zatwierdzenia została naprawiona.

Jednak ta inna opcja „Squash commit”… Zawsze się zastanawiałem, co to robi ?!

Moje pytanie brzmi:

Czy ktoś po prostu wyjaśniłby mi, jaka jest dokładna różnica między zatwierdzeniem Squasha a zatwierdzeniem poprawkowym w rozszerzeniach Git / Git ? Wyglądają trochę ... „podobnie” do mnie:

Nie wiem, co konkretnie robi z tym Git Extensions, ale git rebasema opcję automatycznego zgniatania lub poprawiania zatwierdzeń za pomocą squasha! lub napraw! przedrostki odpowiednio:

   --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).

Różnica między squash i fixup polega na tym, że podczas rebase squashoperacja wyświetli monit o połączenie komunikatów oryginału i zatwierdzenia typu squash, podczas gdy fixupoperacja zachowa oryginalną wiadomość i odrzuci wiadomość z zatwierdzenia fixup.

Mówiąc najprościej, podczas zmiany bazy serii zatwierdzeń, każde zatwierdzenie oznaczone jako a squash, daje możliwość użycia jego wiadomości jako części komunikatu picklub rewordzatwierdzenia.

Kiedy używasz, fixupwiadomość z tego zatwierdzenia jest odrzucana.

Z dokumentu git-rebase, sekcja „tryb interaktywny” :

Jeśli chcesz spasować dwa lub więcej zatwierdzeń w jedno, zamień polecenie „wybierz” dla drugiego i kolejnych zatwierdzeń na „squash” lub „fixup”. Jeśli zatwierdzenia miały różnych autorów, złożone zatwierdzenie zostanie przypisane autorowi pierwszego zatwierdzenia. Sugerowanym komunikatem o zatwierdzeniu dla zwiniętego zatwierdzenia jest konkatenacja komunikatów o zatwierdzeniach pierwszego zatwierdzenia i tych z poleceniem "squash", ale pomija komunikaty o zmianach w zatwierdzeniach za pomocą polecenia "fixup".

Jeśli pytanie brzmi, jaka jest różnica między squashi fixupw git podczas wykonywania git rebase --interactive , to odpowiedzią jest komunikat o zatwierdzeniu .

s, squash <commit> = użyj zatwierdzenia, ale połącz go z poprzednim zatwierdzeniem

f, fixup <commit>= jak "squash", ale odrzuć komunikat dziennika tego zatwierdzenia

Na przykład:

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

Komunikat zatwierdzenia po zmianie bazy w przypadku 1 wyglądałby:

father commit message

child commit message

podczas gdy komunikat o zatwierdzeniu w przypadku 2 to:

father commit message
# no sub messages

Majstrowałem przy rozszerzeniach gita i nie mogłem zmusić go do zgniatania wielu zatwierdzeń w jedno. Aby to zrobić, musiałem skorzystać z wiersza poleceń i uznałem ten post za pomocny

git rebase -i Head~2

To jest interaktywna rebase i zwróć uwagę na następujące kwestie:

• ~ 2 tutaj odnosi się do liczby zatwierdzeń, które chcesz zaangażować w tę operację, łącznie z bieżącą głową
• Musisz wyedytować kolejne interaktywne okno edycji, pozostawić pierwszy element jako „wybierz” i zastąpić kolejne wiersze „squash”. Instrukcje w powyższym linku są znacznie jaśniejsze, jeśli są nieprzejrzyste.

Dlaczego nie zapytać samego gita? Kiedy rebase z git-bash, mówi:

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

Więc widzisz:

s, squash = użyj zatwierdzenia, ale łączy się z poprzednim zatwierdzeniem

f, fixup = jak "squash", ale odrzuć komunikat dziennika tego zatwierdzenia