Wie wurden diese Git-Commits in den falschen Zweig dupliziert?

Question

Ich versuche einem Mitarbeiter zu helfen, herauszufinden, worum es bei seiner kürzlichen Zusammenführung zu einer Reihe von "leeren Commit" -Warnungen ging. Ich öffnete gitk und sah etwa so aus:

_o (Z) Merge branch 'new-branch'        (yesterday) 
o | (Y) Fix bad merge           (person 1) 
o_| (X) Merge branch 'master' into new-branch     (recent) 
o | (W) Last legitimate commit that belongs on new-branch  (person 1) 
| |  ... work on master ... 
o | (F) Legitimate commit that actually belongs on new-branch (person 2) 
| |  ... work on master ... 
o | (E) Legitimate commit that should have been on master  (person 2) 
o | (D') Even more work etc...        (committed by person 2) 
o | (C') More work in master         (committed by person 2) 
o | (A') Normal work in master        (committed by person 2) 
| o (D) Even more work etc...         (authored by random person) 
| o (C) More work in master         (authored by random person) 
o | (B) Starting to work on new-branch      (person 1) 
|_o (A) Normal work in master         (authored by random person) 
o Common Ancestor            (weeks ago) 

So offensichtlich die beiden Menschen auf diesem Zweig arbeiten, sollten häufiger von Master in ihrer Branche zusammengeschlossen haben, und dann würden diese Haufen merge Warnungen waren offensichtlicher . Das Teammitglied, dessen Name im Committer-Feld der Duplicate-Commits stand, sagt, dass er wahrscheinlich eine Pull-Rebase gemacht hat, um sie zu verursachen, aber ich kann mir nicht vorstellen, wie das funktionieren könnte. Kann mir jemand erklären, was passiert sein könnte?

Ich bin nicht auf der Suche nach einer Möglichkeit, die Zusammenführung Warnungen zu beheben, da sie gutartig schien. Ich möchte nur verstehen, was passiert ist, damit ich verhindern kann, dass es in der Zukunft passiert. Mein Team ist relativ neu für Git, also versuche ich ihnen zu helfen, es in einem kleinen Schritt nach dem anderen zu verstehen, wobei ich größtenteils auf Versuch und Irrtum zurückblicke.

Danke!

Answer 1

Wenn Sie eine Zweigstelle für eine Zweigstelle erstellen, schreiben Sie die Zweigstelle dieser Zweigstelle neu. Für alle betroffenen Commits werden mindestens ihre IDs geändert (auch wenn innerhalb des Commits keine Änderungen am Inhalt vorgenommen wurden). Aus diesem Grund könnte es so aussehen, als ob Sie doppelte Commits haben, was Sie jedoch nicht tun. Sie haben zwei verschiedene Commits mit demselben Inhalt.

Die Art und Weise, dieses "Duplicate-Commits" -Verhalten zu reproduzieren, besteht in der Regel darin, eine Verzweigung einer Verzweigung zu erstellen, die bereits an ein Remote-Repository gesendet wurde, und sie dann wieder mit derselben Remote-Verzweigung zusammenzuführen. Die Rebase ändert die IDs Ihrer Commits und die Zusammenführung behält beide Paare von "doppelten" Commits bei, obwohl ihre Änderungen denselben Inhalt ergeben.

1. In Ihrem vorhandenen Repository, einen neuen „Feature“ Zweig vom „Master“ Zweig erstellen: git checkout -b feature
2. eine neuen Datei „Datei-feature.txt“ hinzufügen und es auf dem „Feature“ Zweig begeht : git add . ; git commit -m "added new file on master branch"
3. wechseln Sie in den Zweig "Master" hinzufügen und eine andere neue Datei gibt und dass begehen, auch: git checkout master ; git add . ; git commit -m "added new file on master branch"
4. auf der Remote-Repository den Funktionszweig Push: git checkout feature ; git push --set-upstream origin feature
5. Jetzt, Führen Sie einen Rebase des "Feature" Zweigs auf "Master" Zweig: git rebase master
6. Wenn Sie jetzt versuchen, diese "Feature" -Abzweig in das Remote-Repository zu schieben, erhalten Sie eine Fehlermeldung, dass Sie eine "git pull" tun müssen zuerst. Dies ist der Punkt, wo Sie tatsächlich Ihre "Duplikat" Commits erhalten, wegen der Zusammenführung (git pull ist eine Kurzschrift für git fetch ; git merge), auch daran erinnern, dass Commits 'Inhalt gleich sind, aber aufgrund der Rebase der Branche, die Commits' IDs sind jetzt anders und so, sie werden als eine andere Sache betrachtet, also: git pull
7. Untersuchen Sie Ihre Filiale jetzt in einer GUI, mit "git gui" (zum Hauptmenü navigieren - Repository - Feature Geschichte der Visualisierung) und Sie werden etwas sehen wie folgt aus:
8. Oder benutzen sie einfach git log es zu sehen, direkt in der Befehlszeile: