Unser Team macht mehrere Projekte in PHP. Wir haben fälschlicherweise einen Ordner von einem Projekt auf einen anderen übertragen. Jetzt möchten wir diesen bestimmten Commit aus dem Projekt entfernen. Wenn wir den bestimmten Ordner / Commit aus dem Projekt entfernen, gibt es kein Problem für unser Projekt.
Wenn wir nur den Ordner entfernen und das neue Festschreiben an der aktuellen Position absetzen, wird der Ordner entfernt, aber er verbleibt im Verlauf von Git. Also, wir wollen es vollständig aus Refs, Geschichte und anderen Dingen von Git entfernen.
Wir können auch einen separaten Zweig erstellen, aber die Festschreibungsreferenzen der Autoren würden verloren gehen. Wir möchten nur dieses bestimmte Commit entfernen. Wir haben kein Problem damit, die Geschichte umzuschreiben oder neu zu begründen, wissen aber nicht, wie wir es machen sollen.
Im Projekt haben wir 136 Commits gemacht und wollen Commit Nr. 76 entfernen. Die erforderlichen Informationen über SHA sind wie unter
%Vor%Ich habe alle bereitgestellten Methoden ausprobiert, d. h. Rebase und Cherry-Pick. Ich hier, um vollständige Informationen über die Methoden und die Dinge, die von mir getan werden, zu helfen, um Dinge mit besserer Sicht zu verstehen
Um zu überprüfen, was das Beste ist, habe ich diese Dinge getan:
Verzweigen Sie das Remote-Repo, damit das Original intakt bleibt und die Dinge leicht verstanden werden können. Machen Sie also kein Original-Repo, bis Sie sicher sind, dass die Dinge richtig sind oder nicht.
nahm zuerst die saubere Kopie von Git Repo. Im Allgemeinen, wenn wir andere Dinge speichern oder tun, die in Git als lokale Git-Datenbank gespeichert sind. Also, diese Git-Datenbank hat keine lokalen oder temporären Dinge.
Ich habe die Gesamtzahl der Bytes berechnet, die von dem Ordner .git übernommen wurden. Da der Repo sauber ist, wären hier die minimalen Bytes korrekt. Um weiter in die Tiefe zu gehen, habe ich sowohl die aufgenommenen Bytes als auch die auf der Platte entnommenen Bisse notiert. Da beide verschiedene Dinge sind und sie sind:
Bytes - 7.963.769 und Größe auf der Festplatte - 8.028.160
Wenn Sie Windows verwenden und einen Anti-Virus installiert haben, müssen Sie den Aktiv / Echtzeit-Modus deaktivieren. Als Dinge zu tun Git brauchen schnellen Zugriff von E / A-Dateien zu überprüfen. Was passiert, wenn eine Datei von Git erstellt wird, sperrt der aktive Modus den neuen Created for checking-Virus und wenn Git versucht, erneut darauf zuzugreifen, dass es aufgrund der Sperrung durch Antivirus fehlschlägt. Im Fehlerfall haben Sie Ihren Prozess erneut von 1 gestartet.
Bei der Re-Basing-Methode kann auf zwei Arten erfolgen. Man ist durch --onto und andere ist mit -i.
Ich habe den folgenden Befehl verwendet:
%Vor%und es hatte den vim Editor geöffnet und ich sehe die Liste der Commits ab 162f833c nicht vom Master. Wenn das Ende die folgenden Zeilen zur Verfügung gestellt werden.
%Vor%Ich habe eine Zeile entfernt, so dass der Commit verloren geht und die Datei gespeichert und der Editor beendet wird. Wenn ich ihn beendet habe, habe ich angefangen zu rebasieren:
%Vor%Und dann versucht, das Protokoll zu überprüfen, um zu sehen, dass das Festschreiben verloren gegangen ist oder nicht, und im Protokoll konnte ich das Festschreiben nicht finden, das ich löschen möchte. Bedeutet, dass der Befehl erfolgreich abgeschlossen wurde. Ich habe versucht, den Status zu überprüfen:
%Vor%Da das Commit gelöscht wird, muss es auf der entfernten Seite, von der es abgeleitet wurde, gepusht werden. Also, schob die Commit mit der Kraft, um früheren Code zu überschreiben.
%Vor%Danach habe ich den lokalen Repo entfernt und den Repo und die Größe erneut abgerufen:
%Vor%Nachdem ich viele Blogs und das Handbuch durchgegangen bin, habe ich 1 Blog hier gefunden, der mich wirklich wissen lässt, wie man es benutzt. Also der Befehl, den ich verwendet habe, ist:
%Vor%und der Ausgang ist:
%Vor%Und dann versucht, das Protokoll zu überprüfen, um zu sehen, dass das Festschreiben verloren gegangen ist oder nicht, und im Protokoll konnte ich das Festschreiben nicht finden, das ich löschen möchte. Bedeutet, dass der Befehl erfolgreich abgeschlossen wurde. Ich habe versucht, den Status zu überprüfen:
%Vor%Also, mit einem einzigen Befehl sind alle Dinge erledigt und dann habe ich einen force push gemacht, um die Bytes usw. wie früher
zu überprüfen %Vor%Danach habe ich den lokalen Repo entfernt und den Repo und die Größe erneut abgerufen:
%Vor%Also nach der Rebasemethode. Ich genehmige wirklich die --onto Methode zum Löschen des Commits dazwischen, da es ein einzelner Befehl ist und die Bytes auch marginal höher gespeichert werden als die -i Methode. Der wirkliche Vorteil ist, dass wir keine zusätzlichen Dinge in --onto Methode machen müssen.
Cherry-wählen Sie eine wirklich gute Methode, aber gehen Sie durch viele Befehle und Sie müssen einige Vorsichtsmaßnahmen beim Ausführen der Befehle ausführen. Zuerst muss ich eine separate Protokolldatei mit
erstellen %Vor%Was mir das Protokoll des Repos gezeigt hat, wie wir es immer wieder sehen müssen. Ermitteln Sie aus diesem Repo den Commit, den Sie löschen möchten, und kopieren Sie den SHA-Schlüssel als letzte Commit-Bedeutung und identifizieren Sie damit das Commit, bis zu dem wir nichts ändern wollten. Der nächste Befehl wäre also
%Vor%generierte Ausgabe:
%Vor%Also, bis zuletzt Good commit haben wir einen neuen Zweig erstellt. Also, Dinge bis zum Schluss Gutes Commit ändert sich nicht. Ich führe erneut den folgenden Befehl aus, um alle guten Commits anzuzeigen:
%Vor%Ich habe die Welt entfernt - alle als, ich möchte nur die Commits der Zweig Reparatur sehen. Da zeigte es mir gute Commits bis richtig markiert. Nun sollte der nächste Befehl mit Vorsicht verwendet werden, da er das schlechte Commit als Startpunkt und Endpunkt als letztes Commit enthält und wie folgt aussehen würde:
%Vor%Ausgabe:
%Vor%Was dieser Befehl tut, dass er alle Commits, die das oben bereitgestellte erste Commit verlassen, d. h. (162f833) bis zum letzten Commit (5d39775), bereitstellt. Der Wert für sha commits wird entsprechend geändert, da die Commits einzeln neu eingegeben werden.Jetzt ist es an der Zeit, das Protokoll als:
anzusehen %Vor%Ausgabe als:
%Vor%Wenn Sie sich also das Diagramm ansehen, müssen Sie wissen, dass es alle Commits außer dem schlechten Commit erneut bestätigt hat. zeige dir alle alten sha Schlüssel mit neuen Schlüsseln. Wenn alles in Ordnung ist, müssen wir den Reparaturzweig als Master erstellen und den Masterzweig wie folgt löschen:
%Vor%und Ausgabe als:
%Vor%Erster Master-Zweig der Kasse, damit wir die Änderungen am Master-Zweig übersteuern können. Dann
%Vor%und Ausgabe als:
%Vor%Es wird die Commits nach dem guten Commit verwerfen und jetzt müssen wir den Reparaturzweig mit Master zusammenführen:
%Vor%und Ausgabe als:
%Vor%Nun, wenn Sie das Protokoll anzeigen, zeigt es Ihnen nicht das schlechte Commit und alles ist erledigt. Ich habe einen force push gemacht, um die Bytes usw. zu überprüfen, wie früher
%Vor%Danach habe ich den lokalen Repo entfernt und den Repo und die Größe erneut abgerufen:
%Vor%Rebase --auf [Erstes]
%Vor%Cherry Pick [Sekunde]
%Vor%Rebase -i [dritte]
%Vor%Ich möchte dem Befehl git rebase --onto den Vorzug geben, da die Dinge auf einfache Weise mit einem einzigen Befehl erledigt werden.
In Ihrem Master-Zweig können Sie interaktiv rebasen:
%Vor%Dies wird bei dem Commit vor der anstößigen Commit oben auf der Seite rebase. Jetzt entfernen Sie einfach den fehlerhaften Commit von der Liste, speichern Sie und existieren Sie den Editor (Standard in * nix-Plattformen ist vi).
Dies wird Ihren Zweig auf den Commit vor dem problematischen setzen, ohne es, was das zu sein scheint, was Sie erreichen wollen.
Sie können interaktives Rebase verwenden.
Da das Commit, das Sie löschen möchten, das sha1 162f833c hat, dann tun Sie einfach git rebase -i 162f833c^
Ein Texteditor wird mit einer Liste von Commits geöffnet. Löschen Sie einfach die Zeile, die dem Commit entspricht, das Sie löschen, speichern und schließen möchten.
Als ein Sicherheitsnetz, wenn ich solche Sachen mache, setze ich gerne zuerst einen TAG auf meinen HEAD, damit, wenn etwas schief geht, ich einfach dieses Tag auschecken und meinen ursprünglichen Zustand abrufen kann.
Sie können dafür auch git cherry-pick verwenden:
git rebase ist vielleicht besser, also zeige ich zumindest, dass es in der Regel mehrere Wege gibt. Schließlich ist die Rebase so mächtig, dass "alle sinnvollen Operationen in git in Bezug auf den Rebase-Befehl ausgedrückt werden können" ( Linus Torvalds ).
Sie können eine Festschreibung automatisch entfernen und den Verlauf umschreiben (wobei ${ref_to_delete} die zu entfernende Festschreibung ist und davon ausgeht, dass master der Zweig ist, auf dem sie sich befindet):
Wenn Sie ein Remote-Repository verwenden, müssen Sie push mit -f :
git Rebase -i 32603274 .. Dies wird eine riesige Liste von Commits zeigen.
wähle 162f833c .. Wähle ...
Ändern Sie das erste Commit als d 162f833c ..
und speichern Sie es.
Dies wird den 76. Commit allein fallen lassen.
Tags und Links git github git-commit repository