Ich habe zwei Filialen devel und next. In devel habe ich eine mehr oder weniger große Menge an Commits. Einige der Commits sind Rosinenpickerei next. Außerdem habe ich einige Commits zu next hinzugefügt, mit denen zusammengeführt wird devel.

Jetzt würde ich gerne sehen, was darin fehlt nextdamit ich die Änderungen ausführlich testen kann, bevor ich sie einbringe next. Meine Frage ist nun, wie kann ich sehen, welche Commits drin sind devel aber nicht im nächsten?

Der wenig genutzte Befehl git cherry zeigt Ihnen die Commits, die noch nicht ausgewählt wurden. Die Dokumentation für git cherry ist Hieraber kurz gesagt, Sie sollten nur in der Lage sein, Folgendes zu tun:

git checkout devel
git cherry next

… und sehen Sie sich die Ausgabe ungefähr so ​​​​an:

+ 492508acab7b454eee8b805f8ba906056eede0ff
- 5ceb5a9077ddb9e78b1e8f24bfc70e674c627949
+ b4459544c000f4d51d1ec23f279d9cdb19c1d32b
+ b6ce3b78e938644a293b2dd2a15b2fecb1b54cd9

Die Commits, die mit beginnen + werden diejenigen sein, die Sie noch nicht hineingepflückt next. In diesem Fall habe ich bisher nur einen Commit ausgewählt. Vielleicht möchten Sie die hinzufügen -v Parameter zum git cherry Befehl, sodass er auch die Betreffzeile jedes Commits ausgibt.

Außerdem können Sie verwenden

git log --left-right --graph --cherry-pick --oneline devel...next

um eine schöne Liste zu erhalten tatsächlich verschiedene Commits, die nicht zwischen den Zweigen geteilt werden.

Das entscheidende Wort ist --cherry-pick

--cherry-pick

Lassen Sie jeden Commit aus, der die gleiche Änderung wie ein anderer Commit auf der “anderen Seite” einführt, wenn die Menge der Commits mit symmetrischen Unterschieden begrenzt ist. Wenn Sie zum Beispiel zwei Zweige haben, A und B, ist ein üblicher Weg, alle Commits auf nur einer Seite davon aufzulisten, mit –left-right, wie im obigen Beispiel in der Beschreibung dieser Option. Es zeigt jedoch die Commits, die aus dem anderen Zweig herausgepickt wurden (z. B. „3rd on b“ kann aus Zweig A herausgepickt werden). Mit dieser Option werden solche Commits-Paare von der Ausgabe ausgeschlossen.

Aktualisieren Wie in einem Kommentar erwähnt, wurden neuere Versionen von git hinzugefügt --cherry-mark:

--cherry-mark

Wie –cherry-pick (siehe unten), aber markieren Sie äquivalente Commits mit =, anstatt sie wegzulassen, und nicht äquivalente mit +.

Sie könnten versuchen, Git-Log-Teilmengen zu erstellen:

git log --oneline devel ^next

Wie wäre es mit

git log next..devel

Das Ergebnis ähnelt der Antwort von Byran (unterschiedliche Reihenfolge der Commits), aber unsere beiden Antworten werden Commits erzeugen, die sich zwischen den Zweigen unterscheiden, sondern nur zeigen, was sich in einem Zweig befindet und nicht in dem anderen.

Um die Liste der Commits zu erhalten, die nicht in den Release-Branch (next) integriert wurden, können Sie Folgendes verwenden:

git rev-list --reverse --pretty="TO_TEST %h (<%ae>) %s" --cherry-pick --right-only origin/release_branch...origin/development_branch | grep "^TO_TEST " > NotIntegratedYet.txt

Überprüfen git-rev-liste Für mehr Information.

@Mark Longair hat es hier in seiner Antwort auf den Punkt gebracht, aber ich möchte einige zusätzliche Einblicke hinzufügen.

Damit verbunden und die Beantwortung der Frage, wie man einen großen Pull-Request (PR) aufteilt, insbesondere wenn das Squashing Ihrer Commits aufgrund einer oder mehrerer Zusammenführungen von master mit Ihrem feature_branch unpraktisch ist

Meine Situation:
Ich habe groß gemacht feature_branch mit 30 Commits und öffnete einen Pull Request (PR) auf GitHub, um ihn darin zusammenzuführen master. Sich verzeigen master hat eine Tonne unter mir geändert und 200 Commits meiner erhalten feature_branch hatte nicht. Um Konflikte zu lösen, habe ich es getan git checkout feature_branch und git merge master zu verschmelzen master‘s ändert sich in meine feature_branch. Ich habe mich dafür entschieden merge eher, als rebase auf den neuesten Master, sodass ich Konflikte nur ein einziges Mal lösen müsste, anstatt möglicherweise 30 Mal (einmal für jeden meiner Commits). Ich wollte meine 30 Commits nicht zuerst in 1 quetschen und dann auf die neuesten umbasieren master da dies den Kommentarverlauf der GitHub-Reviews in der PR löschen könnte. Also habe ich Master in meinen Feature-Zweig gemergt und Konflikte ein einziges Mal gelöst. Alles war gut. Meine PR war jedoch zu groß, als dass meine Kollegen sie überprüfen könnten. Ich musste es aufteilen. Ich ging, um meine 30 Commits zu quetschen und OH NEIN! WO SIND SIE? SIE SIND ALLE VERMISCHT MIT master‘s 200 letzten Commits jetzt, weil ich zusammengeführt habe master in mein feature_branch! WAS KANN ICH TUN?

git cherry Verwendung, falls Sie es versuchen möchten git cherry-pick individuelle Zusagen:

git cherry zur Rettung (irgendwie)!

Um alle Commits zu sehen, die drin sind feature_branch aber NICHT drin master Ich kann:

git checkout feature_branch
git cherry master

ODER ich kann Commits von JEDEM Zweig prüfen, ohne sicherzustellen, dass ich eingeschaltet bin feature_branch zuerst durch tun git cherry [upstream_branch] [feature_branch], so was. Auch hier wird überprüft, welche Commits drin sind feature_branch sind aber NICHT drin upstream_branch (master in diesem Fall):

git cherry master feature_branch

Hinzufügen -v zeigt auch die Betreffzeilen der Commit-Nachricht:

git cherry -v master

Weiterleitung an “word count” “-lines” (wc -l) zählt, wie viele Commits es gibt:

git cherry master | wc -l

Sie können diese Anzahl mit der Commit-Nummer vergleichen, die in Ihrem GithHub-PR angezeigt wird, um ein besseres Gefühl zu haben git cherry funktioniert wirklich. Sie können die Git-Hashes auch einzeln vergleichen und sehen, dass sie übereinstimmen git cherry und GitHub. Beachten Sie, dass git cherry zählt KEINE Zusammenführungs-Commits, bei denen Sie zusammengeführt haben master hinein feature_branch, aber GitHub WIRD. Wenn Sie also eine kleine Diskrepanz in der Zählung sehen, suchen Sie auf der GitHub-PR-Commit-Seite nach dem Wort „merge“ und Sie werden wahrscheinlich sehen, dass dies der Übeltäter ist, der nicht auftaucht git cherry. Bsp.: ein Commit mit dem Titel “Branch ‘master’ mit feature_branch zusammenführen” wird in der GitHub-PR angezeigt, aber nicht, wenn Sie es ausführen git cherry master feature_branch. Das ist in Ordnung und wird erwartet.

Jetzt habe ich also ein Mittel, um herauszufinden, welche Diffs ich auf einen neuen Feature-Zweig aufheben möchte, um diesen Diff aufzuteilen: Ich kann ihn verwenden git cherry master feature_branch lokal oder sehen Sie sich die Commits in GitHub PR an.

Wie Squash helfen könnte – wenn wir nur Squash könnten:

Eine Alternative ist jedoch, mein großes Diff aufzuteilen Alle 30 meiner Commits in einem zusammenfassen, diesen auf einen neuen Feature-Branch patchen, den Patch-Commit weich zurücksetzen und dann verwenden git gui Stücke Datei für Datei, Chunk für Chunk oder Zeile für Zeile hinzuzufügen. Sobald ich ein Subfeature erhalte, kann ich das, was ich hinzugefügt habe, committen, dann einen neuen Branch auschecken, weitere hinzufügen, committen, einen neuen Branch auschecken usw., bis ich mein großes Feature in mehrere Subfeatures aufgeteilt habe . Das Problem ist, dass meine 30 Commits aufgrund meiner mit den anderen 200 Commits anderer Leute vermischt sind git merge master in mein feature_branchalso ist ein Rebasing unpraktisch, da ich 230 Commits durchsuchen müsste, um meine 30 Commits neu zu ordnen und zu quetschen.

So verwenden Sie eine Patch-Datei als viel einfacheren Ersatz für Squashing:

Eine Problemumgehung besteht darin, einfach eine Patch-Datei zu erhalten, die ein “Squash-Äquivalent” aller 30 meiner Commits enthält, und sie auf einen neuen Fork von zu patchen master (ein neuer Unterfunktionszweig) und arbeiten Sie von dort aus wie folgt:

git checkout feature_branch
# ensure I have the latest changes from master merged into feature_branch
git merge master 
# Obtain a patch file, which is the equivalent of a squash of my 30 commits into 1 commit:
git diff master..feature_branch > ~/mypatch.patch
git checkout master
# Create a new, sub-feature branch
git checkout -b feature_branch2
# Patch the 30 commit patch file onto it:
git apply ~/mypatch.patch

Jetzt habe ich meinen 30-Commit-Patch alle lokal angewendet, aber nicht bereitgestellt und nicht festgeschrieben.

Jetzt benutzen git gui um Dateien, Chunks und/oder Zeilen hinzuzufügen und Ihren großen PR oder “Diff” aufzubrechen:

Beachten Sie, dass, wenn Sie nicht haben git guikönnen Sie es einfach in Ubuntu mit installieren sudo apt install git-gui.

Ich kann jetzt laufen git gui und beginne mit dem Hinzufügen von Dateien, Chunks und/oder Zeilen (durch Rechtsklick im Git-GUI-Programm) und unterteile den 30-Commit-Feature-Zweig wie oben beschrieben in Unterzweige, indem du wiederholt einen neuen Feature-Zweig hinzufügst, festschreibst und dann forkst und Wiederholen dieses Zyklus, bis alle Änderungen zu einem Unterfunktionszweig hinzugefügt wurden und meine 30-Commit-Funktion erfolgreich in 3 oder 4 Unterfunktionen aufgeteilt wurde. Ich kann jetzt für jede dieser Unterfunktionen eine separate PR eröffnen, und sie werden für mein Team einfacher zu überprüfen sein.

Verweise:

1. Erstellen Sie eine Patch- oder Diff-Datei aus dem Git-Repository und wenden Sie sie auf ein anderes Git-Repository an