Git: Wie schnell vorwärts zu ignorieren und Ursprung zu früheren Commit zurückzusetzen?

ich benutzte

 git reset --hard dc082bc ... 

aufgrund einiger schlechter Commits zur Verzweigung zurück in einen erforderlichen vorherigen Zustand zurückkehren. 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 versucht, git Push Origin Master, aber es gibt den folgenden Fehler

  !  [Abgelehnt] Zweig -> Zweig (Nicht-Schnellvorlauf)
 error: es ist mir nicht gelungen, einige refs auf 'git@github.com: xxx / xxx.git' zu schieben
 Um zu verhindern, dass Sie den Verlauf verlieren, wurden Aktualisierungen ohne Schnellvorlauf abgelehnt
 Führen Sie die Remote-Änderungen zusammen, bevor Sie erneut drücken.  Siehe den 'Hinweis zu
 Schnellvorlauf 'von' git push --help 'für Details.

Solutions Collecting From Web of "Git: Wie schnell vorwärts zu ignorieren und Ursprung zu früheren Commit zurückzusetzen?"

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

 --force 

Normalerweise verweigert der Befehl die Aktualisierung einer Remote-Referenz, die kein Vorgänger 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 vom Ursprung her gezogen haben, kann das ein gewisses Rebase-Problem auf ihrer Seite verursachen.
Diese Operation kann auf der Serverseite blockiert werden, wie Ebneter hervorhebt (in den Kommentaren):

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 entfernten Server durchgeführt werden.

Im Fall von GitHub sind solche Einstellungen jedoch für den Benutzer, der seinen GitHub-Repo verwaltet, nicht ohne weiteres verfügbar .
Wenn Sie also git push --force aus Versehen git push --force , müssen Sie nur noch den GitHub – Support kontaktieren, um ihre lokalen Refitlogs (dh “GitHub”) zu überprüfen und zu sehen, ob sie alte Commits wiederherstellen können.
(Da Reflogs lokal sind, wurde mir kürzlich in Erinnerung geblieben . So sind Commits, die während einer push --force durch neue ersetzt werden, nur noch sichtbar, wenn am GitHub schon keine ‘ git gc ‘ oder ‘ git prune ‘ stattfand Serverseite)

So besteht Marco Ceppi (in den Kommentaren):

das könnte wirklich die lokalen Repos anderer Kontributoren durcheinander bringen, wenn du Pushs erzwingst – obwohl es Zeiten sind, in denen es nur ein notwendiges Übel ist (ich musste das vielleicht zweimal in meinem Leben machen, wenn ich Git benutze)

Um zu meiner vorherigen Antwort zu kommen und die Tatsache anzugehen, dass ein erzwungener git push wirklich die lokalen Repos anderer Kontributoren durcheinander bringen kann, wird Git 1.8.5 (bevorstehendes Q4 2013) eine neue Option sehen:

 git push --force-with-lease 

Sehen Sie sich den Ursprung dieser Option in diesem Thread an :

Wenn etwas in ” origin ” zu dem Zweig passiert, den Sie forcieren oder löschen, seit Sie es abgerufen haben, können Sie am Ende die Arbeit anderer verlieren .

Jemand, der sich nicht der Entscheidung bewusst ist, den Zweig zurückzuspulen und neu aufzubauen, kann versuchen, zwischen dem Zeitpunkt, den Sie zum Neubasen abgerufen haben, und dem Zeitpunkt, zu dem Sie ihn mit dem Ergebnis des Rebasings ersetzt haben, zum Zweig zu wechseln.

Wir können make these pushes safer indem wir dem Benutzer optional ” git push ” sagen lassen:

Ich forciere / lösche, basierend auf der Annahme, dass der Wert von ‘branch’ immer noch bei diesem Objekt ist.
Wenn diese Annahme nicht mehr zutrifft, dh wenn der Zweig seit meiner Vorbereitung auf diesen Push etwas passiert ist, bitte gehen Sie nicht weiter und scheitern Sie an diesem Push.

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

--force-with-lease schützt alle Remote-Refreshs, die aktualisiert werden sollen, indem sie ihren aktuellen Wert dem eines vernünftigen Standards anpasst, sofern nicht anders angegeben;

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

Das erklärt den “Leasing” -Teil dieser Option:

force-with-lease “: Sie gehen davon aus, dass Sie den Leasingvertrag für die Referenz übernommen haben, als Sie entschieden haben, wie der umbasierte Verlauf sein sollte, und Sie können nur zurückschieben, wenn der Leasingvertrag nicht aufgetriggers wurde.


Dies wird bereits getestet und in der ” Was ist Kochen in git.git (Aug 2013, # 07; Mi, 28) ” erwähnt:

Übrigens, der Push, der das übliche “muss schnell vorwärts” überschreiben wird, wurde mit der ” force-with-lease ” -Option gemacht, die im next wie force-with-lease gekocht hat:

 $ git fetch ko next $ anchor=$(git rev-parse --verify FETCH_HEAD) $ for remote in ko repo gph github2 do git push --force-with-lease=refs/heads/next:$anchor $remote next done 

Hinweis: ” git push --force-with-lease ” wurde git push --force-with-lease zu melden, ob der Push erforderlich ist, um zu erzwingen (oder schnell zu gehen).

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

push: --force-with-lease Statusbericht 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 weitergeleitet wurde, selbst wenn sie zwangsweise aktualisiert wurde.


Beachten Sie, dass diese Option ignoriert / umgangen wird, wie in Git 2.13 (Q2 2017) erläutert .