Ich habe einen Upstream eines großen Projekts mit meinem lokalen Git Repo verbunden. Vor der Zusammenführung hatte ich eine kleine Menge an Geschichte, die leicht zu lesen war, aber nach der Zusammenführung ist jetzt eine riesige Menge an Geschichte in meinem Repo. Ich brauche nicht die gesamten History-Commits aus dem Upstream-Repo.
Nach diesem Upstream-Merge wurden weitere Commits gemacht, die ich behalten möchte. Wie zerquetsche ich den ganzen Verlauf, der vom Upstream in einen Commit verschmolzen wurde, während ich die Commits beibehalten habe, die nach dem Upstream-Merge gemacht wurden?
Die Lösung, die ich verwendet habe, war, den Verlauf manuell wiederherzustellen. Ich tat dies hauptsächlich, weil ich nicht zu lange nach einer eleganten Lösung suchen wollte und es gab nicht so viel Geschichte (etwa 30 Commits, die ich manuell zusammenführen müsste).
Also habe ich einen Zweig erstellt, bevor ich den riesigen Upstream verschmolzen habe:
%Vor% Dann wurde der Upstream mit der Option --squash erneut zusammengeführt.
Dann wurden die Commits nach der Zusammenführung aus dem alten Zweig (der mit der großen Menge des Upstream-Verlaufs) manuell ausgewählt.
%Vor%Nachdem alle diese Commits in meinen Zweig remove-history-fix übernommen wurden, habe ich den Zweig mit dem Upstream-Verlauf entfernt.
%Vor%Es gibt keine Möglichkeit, dies zu tun, da Sie nicht in der Lage sein werden, das Remoterepository oder ein anderes Projekt desselben Projekts zurückzuschieben oder wieder zusammenzuführen. Beim Squash ändern Sie die Historie, was zu verschiedenen Sha1-Hashes zwischen Ihrem Repository und dem entfernten führt.
Sie müssen mit der großen Geschichte leben.
Ein paar Optionen für Sie:
Nicht genau das, wonach Sie gefragt haben, aber möglicherweise eine gute Alternative und viel einfacher. Dies ermöglicht es Ihnen, git wie normal zu verwenden, verbirgt aber alles, was Sie nicht sehen wollen (vorausgesetzt, das Problem ist, dass der Verlauf Ihr Log und nicht den rohen Speicherplatz durcheinanderbringt. Ich denke, dass das Zusammenführen in Ihrem Zweig nicht funktioniert) Verhindere, dass Git alle Commits von Upstream mit einbezieht, wenn du den Upstream für die Merge-Aktion zuerst geholt hast.).
In diesem Fall würden Sie eine normale Zusammenführung durchführen, aber bei der Protokollierung würden Sie --first-parent zum Befehl hinzufügen.
Zum Beispiel, ohne die Option, die ich haben könnte (davon ausgehen, "Probe mehr" 1 bis 3 war eigentlich viel mehr commits)
%Vor% Aber, wenn ich --first-parent hinzufüge, räumt es auf:
Beachten Sie alle Commits vom Master, nachdem ich abgezweigt habe ("meine lokale Änderung" ist meine abweichende Verpflichtung). Nur Commits, die ich gemacht habe, tauchen auf, auch wenn ich zusammengelegt habe. Wenn ich während der Zusammenführung bessere Commit-Nachrichten verwendet hätte, würde ich vielleicht sogar wissen, was der Stapel von Änderungen war.
Das ist was Sie gefragt haben.
Inspiriert von Ссылка
Was wir hier machen, ist, die Geschichte der Fernbedienung zu zerquetschen, ihre Geschichte durch unsere gequetschte Version aus unserer Perspektive zu ersetzen und die gequetschte Version zusammenzuführen.
In meinem Beispielrepository waren die Revisionen, die vorgelagert wurden, die ich noch nicht zusammengeführt hatte, 682b412 "Probe mehr 1" zum Ursprung / Master (f578cbb "Beispiel mehr 3") (obwohl nicht so lang für dieses Beispiel, tue dort so sind 50 Commits oder was auch immer dazwischen).
Das erste, was ich möchte, ist ein lokaler Zweig der Gegenseite:
%Vor%Als nächstes möchte ich es schnell quetschen
%Vor% Beachten Sie die Tilde ~ -Zeichen. Das führt dazu, dass unser Zweig beim übergeordneten Commit in dem Bereich liegt, in dem wir Squash ausführen wollen, und weil wir --soft angegeben haben, befindet sich unser Index immer noch beim letzten Commit in dem Bereich, den wir zerquetschen möchten. Die Commit-Zeile führt zu einem einzelnen Commit, das aus dem besteht, was unser erstes bis einschließlich letztes war.
Zu diesem Zeitpunkt haben die Ursprung / Master und Squashing Zweige identische Bauminhalte aber unterschiedliche Geschichten.
Nun sagen wir git, dass wenn wir Referenzen auf das Original commit of origin / master sehen, stattdessen unser squashed commit verwenden. Mit git log kann ich sehen, dass das neue "Squashed upstream" Commit 1f0bc14 ist, also tun wir:
Ab hier benutzt dein Git den "Squashed Upstream" Commit.
Zurück zu unserem ursprünglichen Zweig (wenn es "Master" war)
%Vor%Dies scheint den Ursprungs-Master (f578cbb) zusammenzufassen, erhält tatsächlich den Inhalt von 1f0bc14, protokolliert ihn jedoch mit einem Eltern-SHA1 von f578cbb
Wir brauchen den quetschenden Ast nicht mehr, also kannst du ihn loswerden.
Nehmen wir jetzt an, Upstream fügte weitere Funktionen hinzu. In diesem einfachen Beispiel, in der Repo des Upstreams, könnte ein Protokoll folgendes anzeigen:
%Vor%Nachdem wir den Upstream zwar abgerufen haben, sehen wir jedoch, wenn wir uns das Protokoll von unserem Repo aus ansehen:
%Vor%Beachten Sie, wie es scheint, dass wir die Geschichte auch gequetscht haben, und noch wichtiger ist, dass die zerdrückte Upstream-SHA1 diejenige zeigt, die in der Geschichte von Upstream verwendet wird (für sie ist es wirklich die "Sample more 3" -Kommission).
Das Zusammenführen funktioniert also wie gewohnt
%Vor%Aber wir haben kein so überladenes Protokoll:
%Vor%Wenn das "neue Feature" Commit in Upstream eine ähnlich große Anzahl von Commits ist, könnten wir diesen Prozess wiederholen, um auch das zu reduzieren.