Wie verschmilzt Git nach der Arbeit mit Kirschen?

Stellen wir uns vor, wir haben eine masterNiederlassung.

Dann erstellen wir eine newbranch

git checkout -b newbranch

und machen Sie zwei neue Commits für newbranch: commit1 und commit2

Dann wechseln wir zu Master und machen cherry-pick

git checkout master
git cherry-pick hash_of_commit1

Wenn gitkwir uns das ansehen, sehen wir, dass commit1 und seine von Kirschen ausgewählte Version unterschiedliche Hashes haben. Technisch gesehen handelt es sich also um zwei verschiedene Commits.

Schließlich verschmelzen wir newbranchzu master:

git merge newbranch

und sehen Sie, dass diese beiden Commits mit unterschiedlichen Hashes ohne Probleme zusammengeführt wurden, obwohl sie implizieren, dass dieselben Änderungen zweimal angewendet werden sollten, sodass einer von ihnen fehlschlagen sollte.

Führt git beim Zusammenführen wirklich eine intelligente Analyse des Inhalts von Commits durch und entscheidet, dass Änderungen nicht zweimal angewendet werden sollten, oder werden diese Commits intern als miteinander verknüpft markiert?

Kurze Antwort

Keine Sorge, Git wird sich darum kümmern.

Lange Antwort

Im Gegensatz zu z. B. SVN ¹ speichert Git Commits nicht im Delta-Format, sondern basiert auf Snapshots ^2,3 . Während SVN naiv versuchen würde, jedes zusammengeführte Commit als Patch anzuwenden (und aus genau dem von Ihnen beschriebenen Grund fehlschlagen würde), ist Git im Allgemeinen in der Lage, dieses Szenario zu handhaben.

Beim Zusammenführen versucht Git, die Snapshots beider HEAD-Commits zu einem neuen Snapshot zu kombinieren. Wenn ein Teil des Codes oder einer Datei in beiden Snapshots identisch ist (dh weil ein Commit bereits ausgewählt wurde), wird Git ihn nicht berühren.

Quellen

¹ Skip-Deltas in Subversion
² Git-Grundlagen
³ Das Git-Objektmodell

Nach einer solchen Zusammenführung haben Sie möglicherweise zweimal Commits in der Geschichte ausgewählt.

Lösung, um dies zu verhindern Ich zitiere aus einem Artikel, der für Zweige mit doppelten (von Kirschen gepflückten) Commits empfiehlt, Rebase vor dem Zusammenführen zu verwenden:

Git-Merge nach Git-Cherry-Pick: Vermeidung doppelter Commits

Stellen Sie sich vor, wir haben den Hauptzweig und einen Zweig b:

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

Jetzt brauchen wir dringend die Commits b1 und b3 im Master, aber nicht die verbleibenden Commits in b. Wir checken also die Hauptniederlassung und die Cherry-Pick-Commits b1 und b3 aus:

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

Das Ergebnis wäre:

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

Nehmen wir an, wir machen ein weiteres Commit für den Master und wir bekommen:

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

Wenn wir jetzt Zweig b in Master zusammenführen würden:

$ git merge b

Wir würden folgendes bekommen:

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

Das bedeutet, dass die durch b1 und b3 eingeführten Änderungen zweimal in der Historie erscheinen würden. Um dies zu vermeiden, können wir neu aufbauen anstatt zusammenzuführen:

$ git rebase master b

Welches würde ergeben:

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

Schließlich:

$ git checkout master
$ git merge b

gibt uns:

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

EDIT Korrekturen von David Lemons Kommentar angenommen