Git entfernt den Remote-Verlauf nach einem bestimmten Commit
Lesezeit: 4 Minuten
Ich habe ein Git/Gitlab-Repository. Früher haben wir uns direkt auf den Master festgelegt, aber wir haben uns entschieden, für diese Version auf die Verwendung von Feature Branches wie dem Rest der Welt umzusteigen.
Wir müssen unseren Remote-Master auf den Zustand zurücksetzen, in dem er unmittelbar nach der letzten Freigabe war. Wenn sich jemand bereits direkt auf den Master festgelegt hat, wie kann ich ihn in einen sauberen Zustand zurücksetzen und den gesamten Verlauf nach der letzten Veröffentlichung entfernen?
Ich habe jetzt ungefähr eine Stunde gegoogelt und kann keine Antwort auf diese spezielle Frage finden. Tut mir leid, wenn es überflüssig erscheint, es scheint eine so einfache Aufgabe ohne offensichtliche Antwort zu sein!
Mögliches Duplikat von „Mehrere Commits in Git rückgängig machen, die nicht auf Remote übertragen wurden“ und „Wie kann ich den letzten Git-Commit rückgängig machen?“.
– Benutzer456814
26. März 2014 um 22:58 Uhr
@ user3426575 Faire Frage … weil wir müssen. Wir haben mit einer ziemlich großen Version begonnen, und einige Korrekturen müssen in die Produktion gehen, bevor die große Funktion vollständig ist. Wenn wir zu Beginn Feature-Zweige gemacht hätten, hätten wir einfach ein zusätzliches Release herausschneiden und das große Feature rebasen können. Stattdessen müssen wir zum letzten bekannten funktionierenden Codestück zurückgehen.
– Jonathan S. Fisher
27. März 2014 um 3:29 Uhr
Paul Tucher
Um einen lokalen Zweig zurückzusetzen,
git branch -f master last-release
Um eine entfernte Verzweigung zurückzusetzen,
git push -f origin last-release:master
wo last-release ist die Referenz (Commit-ID oder Branche), die Sie zurücksetzen möchten master zu.
(Keines davon wirkt sich auf Ihren Arbeitsbaum aus; Sie können dies sogar von einem bloßen Repo aus tun, wenn Sie dies wünschen.)
Diese Antwort zu akzeptieren, ist wahrscheinlich der “richtige” Weg, dies zu tun
– Jonathan S. Fisher
27. März 2014 um 3:31 Uhr
Bei Verwendung von GitLab als Remote funktioniert dies weder für den Master-Branch noch für einen anderen Branch, der als Standard-Branch des Repositorys in GitLab festgelegt ist. Es funktioniert nicht für den Master, selbst wenn es nicht als Standardzweig festgelegt ist. Getestet mit GitLab 7.9.0.
– akaihola
7. Januar 2016 um 12:43 Uhr
@akaihola, dies schreibt die Geschichte um (“verliert”). Häufig verfügen Master- oder andere wichtige Branches über Schutzmaßnahmen gegen Force Pushes. In diesem Fall müssen Sie die Berechtigungen ändern, da dies sonst nicht möglich ist.
– Paul Tucher
7. Januar 2016 um 16:34 Uhr
Auf GitLab können Sie den Master-Zweig vorübergehend „entschützen“, um dies zuzulassen, da er standardmäßig geschützt ist. Es befindet sich in Ihren Projekteinstellungen (das Zahnradsymbol) und dann unter “Geschützte Zweige”. gitlab.com/help/user/project/protected_branches
– Will
18. Oktober 2016 um 2:56 Uhr
Jonathan S. Fisher
Manchmal posten Sie auf Stack Overflow und finden es eine Sekunde später sofort heraus:
Löschen Sie jetzt Ihr lokales Repo, klonen Sie es erneut.
Vorsichtig sein! Dadurch werden alle lokalen Commits gelöscht, an denen Sie gearbeitet haben, und es werden alle anderen Branches überschrieben, nicht nur master. Das mag funktionieren, aber wisse das.
– Paul Tucher
26. März 2014 um 22:25 Uhr
@Paul Draper: wird es nicht löschen irgendetwas. Alles wird noch einige Zeit im Reflog verfügbar sein (standardmäßig mindestens 2 Wochen).
– zerkms
26. März 2014 um 22:27 Uhr
Ich habe eine separate Kopie des Repos geklont, bevor ich irgendetwas unternehme, falls wir es vermasseln
– Jonathan S. Fisher
26. März 2014 um 22:29 Uhr
@exabrial warum hast du die bestanden --all Flag, wenn Sie nur das zurücksetzen möchten master Zweig?
– Benutzer456814
26. März 2014 um 22:56 Uhr
@zerkms, du hast recht. Sofort wird nichts gelöscht. (Wenn jemand einen Fehler macht, merkt er es hoffentlich schnell.)
– Paul Tucher
27. März 2014 um 5:29 Uhr
Mohammed Maas
Befolgen Sie die folgenden Schritte, indem Sie ein bestimmtes Commit auschecken und den neuen Zweig pushen und die Zweigschutzregel entfernen und das Pushen des neuen Zweigs in den Master erzwingen und die gelöschte Zweigschutzregel wieder hinzufügen.
git log --online (to get the commit hash that you wish to revert)
git checkout <commit-hash>
git branch <new-branch-name> <new-commit-hash>
git push origin <new-branch-name>
# Goto Github and remove branch protection rule (for master)
git push -f origin <new-branch-name>:master
# Go back to Github and add back the branch protection rule (for master/main)
Die obigen Schritte funktionieren nur, wenn Sie eine Reihe der letzten Commits löschen möchten, die versehentlich verschoben wurden (z. B. während Hotfixes oder Releases oder versehentliche Commits in Master/Main).
Die erzwungene Aktualisierung eines öffentlichen Repositorys ist normalerweise eine schlechte Idee. Wenn der Grund dafür nur eine Richtlinienänderung ist, warum belassen Sie den Master-Zweig nicht dort, wo er ist, und lassen ihn beim nächsten Release nachholen?
– Benutzer3426575
26. März 2014 um 22:30 Uhr
Mögliches Duplikat von „Mehrere Commits in Git rückgängig machen, die nicht auf Remote übertragen wurden“ und „Wie kann ich den letzten Git-Commit rückgängig machen?“.
– Benutzer456814
26. März 2014 um 22:58 Uhr
@ user3426575 Faire Frage … weil wir müssen. Wir haben mit einer ziemlich großen Version begonnen, und einige Korrekturen müssen in die Produktion gehen, bevor die große Funktion vollständig ist. Wenn wir zu Beginn Feature-Zweige gemacht hätten, hätten wir einfach ein zusätzliches Release herausschneiden und das große Feature rebasen können. Stattdessen müssen wir zum letzten bekannten funktionierenden Codestück zurückgehen.
– Jonathan S. Fisher
27. März 2014 um 3:29 Uhr