Git: Wie kann ich den schnellen Vorlauf ignorieren und den Ursprung [Zweig] auf einen früheren Commit zurücksetzen?

Question

Git: Wie kann ich den schnellen Vorlauf ignorieren und den Ursprung [Zweig] auf einen früheren Commit zurücksetzen?

7

Ich habe gebraucht

git reset --hard dc082bc...

, um aufgrund einiger fehlerhafter Commits zur Verzweigung in den erforderlichen vorherigen Zustand zurückzukehren. Dies hat meine lokale Filiale gut zurückgespult. Allerdings möchte ich den Zweig auf "Ursprung" auf denselben Commit zurückspulen, damit ich neu beginnen kann. Kann mir jemand sagen, wie man den Ursprungszweig (nicht Master) zu diesem Commit zurückführt?

Ich habe git Push Origin Master versucht, aber es gibt den folgenden Fehler

%Vor%

git commit reverting

igniteflow 02.07.2010, 14:44

quelle

2 Antworten

24

Um zu meiner vorherigen Antwort hinzuzufügen, und um die Tatsache anzugehen, dass ein erzwungenes git push wirklich andere durcheinander bringen kann Lokale Repositories der Mitwirkenden, Git 1.8.5 (bevorstehendes 4. Quartal 2013) sehen eine neue Option:

%Vor%

Siehe den Ursprung dieser Option in diesem Thema :

Wenn etwas in ' origin ' zu dem Zweig passiert, den Sie erzwingen oder löschen, seit Sie es abgerufen haben, können Sie die Arbeit anderer Leute verlieren .

Jemand, der sich nicht über die Entscheidung informiert, den Zweig zurückzuspulen und neu zu erstellen, versucht möglicherweise, zwischen dem Zeitpunkt des Abrufens und dem Zeitpunkt des erneuten Verschiebens zum Zweig zu wechseln.

Wir können make these pushes safer , indem wir dem Benutzer optional erlauben, " git push " dies zu sagen:

Ich forciere / lösche, basierend auf der Annahme, dass der Wert von 'branch' immer noch bei diesem Objekt ist.
  Wenn diese Annahme nicht länger gilt, d. H. Wenn der Zweig seit meiner Vorbereitung auf diesen Push etwas passiert ist, gehen Sie bitte nicht weiter und scheitern Sie an diesem Push.

Sie können die vollständige Dokumentation von --force-with-lease in commit 28f5d17

einsehen

--force-with-lease schützt alle Remote-Refs, die aktualisiert werden, indem der aktuelle Wert wie ein vernünftiger Standardwert festgelegt wird, sofern nicht anders angegeben;

Vorläufig wird "ein vernünftiger Standardwert" vorläufig als "der Wert des Remote-Tracking-Zweigs, den wir für den Verweis des entfernten Servers haben, der aktualisiert wird" definiert, und es ist ein Fehler, wenn wir keinen solchen Remote- haben. Tracking-Zweig.

Das erklärt den "Leasing" -Teil dieser Option:

" force-with-lease ": Sie nehmen an, dass Sie den Leasingvertrag für die Referenz übernommen haben, als Sie die Entscheidung getroffen haben, was der umbasierte Verlauf sein soll, und Sie können nur zurückschieben, wenn der Leasingvertrag nicht unterbrochen wurde.

Dies wird bereits getestet und in der " Was kocht in git.git (Aug 2013, # 07; Mi, 28) ":

Übrigens, der Push, der das übliche "muss schnell vorwärts" überschreiben wird, wurde mit der Option " force-with-lease " durchgeführt, die in next wie folgt gekocht hat:

%Vor%

Hinweis: " git push --force-with-lease " wurde unterrichtet, wenn der Push gemeldet wird benötigt, um zu erzwingen (oder schnell weitergeleitet).

So ist dieser Befehl in seiner Ausgabe mit Git 2.8 (März 2016)

ausführlicher

push: Fix ref Statusberichte für --force-with-lease

Die Option --force--with-lease push führt zu weniger detaillierten Statusinformationen als --force .
  Insbesondere zeigt die Ausgabe an, dass eine Referenz schnell vorgerückt wurde,   auch wenn es Force-aktualisiert wurde.

Achten Sie darauf, dass diese Option ignoriert / umgangen wird, wie in Git 2.13 (2. Quartal 2017) erläutert.

VonC 29.08.2013 08:18

quelle

Tags und Links git commit reverting

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Gulp.js, Aufgabe wird beim Speichern von Dateien zweimal ausgeführt

score 17 · Accepted Answer

Sie können git push --force versuchen, den Push zu erzwingen.

%Vor%

Normalerweise verweigert der Befehl die Aktualisierung einer entfernten Referenz, die kein Vorfahre der lokalen Referenz ist, die zum Überschreiben verwendet wird. Dieses Flag deaktiviert die Überprüfung.
Dies kann dazu führen, dass das Remote-Repository seine Commits verliert. Benutze es vorsichtig.

Wenn also viele Leute den gleichen Zweig bereits aus dem Ursprung gezogen haben, kann das zu einem Problem bei der erneuten Anmeldung führen auf ihrer Seite.
Dieser Vorgang kann auf der Serverseite blockiert werden, wie ebneter (in den Kommentaren) hervorhebt:

Abhängig davon, wie die Fernbedienung konfiguriert ist, funktioniert dies möglicherweise nicht - Alle meine zentralen Repos sind mit receive.denyNonFastForwards = true und receive.denyDeletes = true konfiguriert. In diesem Fall muss eine solche Operation auf dem Remote-Server durchgeführt werden.

Im Fall von GitHub, solche Einstellungen sind nicht sofort verfügbar für den Benutzer, der sein GitHub-Repository verwaltet.
Also, wenn Sie git push --force aus Versehen, ist alles, was Sie übrig haben Öffnen eines Falls für den GitHub-Support , damit sie ihre lokalen (dh "GitHub") Reflogs überprüfen und sehen können, ob sie alte Commits wiederherstellen können.
(Da Reflogs lokal sind, wie ich vor kurzem in Erinnerung hatte , also Commits, die während eines push --force durch neue ersetzt werden, sind nur noch sichtbar, wenn ' git gc ' oder ' git prune ' bereits stattgefunden hat, im GitHub Serverseite)

Also Marco Ceppi besteht (in den Kommentaren):

das könnte wirklich die lokalen Repos anderer Mitwirkenden durcheinander bringen, wenn Sie Pushs erzwingen - obwohl es Zeiten sind, in denen es nur ein notwendiges Übel ist (ich musste das vielleicht zwei Mal in meinem Leben mit Git tun).

Git: Wie kann ich den schnellen Vorlauf ignorieren und den Ursprung [Zweig] auf einen früheren Commit zurücksetzen?

2 Antworten

push: Fix ref Statusberichte für --force-with-lease

push: Fix ref Statusberichte für `--force-with-lease`