Git: Wiederherstellung gelöschter (entfernter) Zweige

Ich muss zwei Git-Zweige wiederherstellen, die ich bei einem Push irgendwie gelöscht habe.

Diese zwei Zweige wurden auf einem anderen System erstellt und dann zu meinem “gemeinsamen” (github) Repository verschoben.

Auf meinem System habe ich (anscheinend) die Zweige während eines Abrufs abgerufen:

~/myfolder> git fetch remote: Counting objects: 105, done. remote: Compressing objects: 100% (58/58), done. remote: Total 62 (delta 29), reused 0 (delta 0) Unpacking objects: 100% (62/62), done. From github.com:mygiturl * [new branch] contact_page -> origin/contact_page 731d1bb..e8b68cc homepage -> origin/homepage * [new branch] new_pictures -> origin/new_pictures 

Gleich danach habe ich versucht, meine lokalen Änderungen an das zentrale Repo zu senden. Aus irgendeinem Grund wurden diese Zweige sowohl aus meinem lokalen System als auch aus dem zentralen Repo gelöscht:

 ~/myfolder> git push Counting objects: 71, done. Delta compression using up to 2 threads. Compressing objects: 100% (43/43), done. Writing objects: 100% (49/49), 4.99 KiB, done. Total 49 (delta 33), reused 0 (delta 0) To git@github.com:mygiturl.git - [deleted] contact_page + e8b68cc...731d1bb homepage -> homepage (forced update) bb7e9f2..e0d061c master -> master - [deleted] new_pictures e38ac2e..bb7e9f2 origin/HEAD -> origin/HEAD 731d1bb..e8b68cc origin/homepage -> origin/homepage e38ac2e..bb7e9f2 origin/master -> origin/master * [new branch] origin/contact_page -> origin/contact_page * [new branch] origin/new_pictures -> origin/new_pictures 

Es ist nicht so einfach, die Äste von der Maschine ihres Geburtsortes zu holen, also würde ich versuchen, sie möglichst von meinem Heimatort zurückzuholen.

Alle git “undo” Informationen, die ich gegoogelt habe, müssen verlorene Commits wiederherstellen. Ich denke nicht, dass das hier gilt, da ich keine UIDs für diese Zweige habe.

Ich würde gerne wissen, wie ich diese zurückbekomme. Ich würde auch gerne wissen, wie sie überhaupt gelöscht wurden und wie ich das in Zukunft vermeiden kann.

EDIT: auf Anfrage, hier ist meine Repo-Konfiguration

 user.name=Craig Walker user.email=github@softcraft.ca alias.unadd=reset HEAD core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=git@github.com:MyGitURL.git remote.origin.mirror=true branch.master.remote=origin branch.master.merge=refs/heads/master alias.undo=reset --hard alias.test=push -f ci HEAD:master alias.st=status alias.ci=commit alias.br=branch alias.co=checkout alias.ch=checkout alias.df=diff alias.lg=log -p alias.who=shortlog -s -- remote.ci.url=ContinuousIntegrationGitURL remote.ci.fetch=+refs/heads/*:refs/remotes/ci/* branch.photo.remote=origin branch.photo.merge=refs/heads/photos remote.foo.url=FooGitURL remote.foo.fetch=+refs/heads/*:refs/remotes/cynthia/* branch.homepage.remote=origin branch.homepage.merge=refs/heads/homepage 

Ich bin kein Experte. Aber du kannst es versuchen

 git fsck --full --no-reflogs | grep commit 

um den HEAD-Commit der gelöschten Verzweigung zu finden und sie zurück zu bekommen.

Ihre gelöschten Zweige gehen nicht verloren, sie wurden in den Ursprungsort / contact_page und origin / new_pictures “remote tracking branches” durch den Abruf kopiert, den Sie angezeigt haben (sie wurden auch durch den Push zurückgeschoben, aber sie wurden in refs / remotes / Ursprung / anstelle von refs / heads /). Überprüfen Sie git log origin/contact_page und git log origin/new_pictures zu sehen, ob Ihre lokalen Kopien auf dem neuesten Stand sind mit allem, von dem Sie denken, dass es dort sein sollte. Wenn irgendwelche neuen Commits auf diese Zweige (von einem anderen Repo) zwischen dem Fetch und Push geschoben wurden, haben Sie diese “verloren” (aber wahrscheinlich könnten Sie sie in dem anderen Repo finden, der diese Zweige zuletzt gedrängt hat). .

Fetch / Push-Konflikt

Es sieht so aus, als würdest du in einem normalen “Remote-Modus” (remote refs / heads / werden lokal in refs / remotes / origin / gespeichert), aber im ‘mirror mode’ (lokale refs / werden auf remote refs / gedrängt) . Überprüfen Sie Ihre .git / config und remote.origin.fetch remote.origin.push Einstellungen remote.origin.fetch und remote.origin.push .

Erstelle eine Sicherung

Bevor Sie Änderungen vornehmen, erstellen Sie ein einfaches tar- oder zip-Archiv oder Ihr gesamtes lokales Repo. Wenn Sie nicht mögen, was passiert, können Sie es mit einem wiederhergestellten Repo erneut versuchen.

Option A: Als Spiegel neu konfigurieren

Wenn Sie Ihren Remote-Repo als Spiegel Ihres lokalen Repo verwenden möchten, tun Sie Folgendes:

 git branch contact_page origin/contact_page && git branch new_pictures origin/new_pictures && git config remote.origin.fetch '+refs/*:refs/*' && git config --unset remote.origin.push && git config remote.origin.mirror true 

Möglicherweise möchten Sie auch alle Ihre refs / remotes / origin / refs löschen, da sie nicht nützlich sind, wenn Sie im Mirror-Modus arbeiten (Ihre normalen Zweige ersetzen die üblichen Remote-Tracking-Zweige).

Option B: Rekonfiguriere als normale Fernbedienung

Aber da es scheint, dass Sie dieses Remote-Repo mit mehreren “Arbeits” -Repos verwenden, möchten Sie wahrscheinlich den Mirror-Modus nicht verwenden. Du könntest das versuchen:

 git config push.default tracking && git config --unset remote.origin.push git config --unset remote.origin.mirror 

Dann werden Sie eventuell die gefälschten refs / remotes / origin refs in Ihrem Remote Repo löschen wollen: git push origin :refs/remotes/origin/contact_page :refs/remotes/origin/new_pictures …

Test Drücken

Probieren Sie git push --dry-run zu sehen, was es mit git push tun würde, ohne Änderungen am Remote-Repo vornehmen zu müssen. Wenn Sie nicht mögen, was es sagt, wird es tun, erholen Sie sich von Ihrem Backup (tar / zip) und versuchen Sie die andere Option.

nur zwei Befehle retten mein Leben

1. Dadurch werden alle vorherigen HEADs aufgelistet

 git reflog 

2. Dadurch wird HEAD zurückgesetzt, um zu bestätigen, dass Sie gelöscht haben.

 git reset --hard  ex. git reset --hard b4b2c02 

Die Daten existieren noch in GitHub, Sie können einen neuen Zweig aus den alten Daten erstellen:

 git checkout origin/BranchName #get a readonly pointer to the old branch git checkout –b BranchName #create a new branch from the old git push origin BranchName #publish the new branch 

Ich denke, dass Sie eine nicht übereinstimmende Konfiguration für ‘holen’ und ‘drücken’ haben, so dass dies dazu geführt hat, dass der Standard-Fetch / Push-Vorgang nicht korrekt ausgeführt wird. Glücklicherweise haben Sie die Zweige, die Sie später gelöscht haben, abgerufen, sodass Sie sie mit einem expliziten Push-Vorgang neu erstellen können.

 git push origin origin/contact_page:contact_page origin/new_pictures:new_pictures 

Wenn das Löschen neu genug ist (wie ein Oh-NO! -Moment), solltest du immer noch eine Nachricht haben:

Deleted branch (was abcdefghi).

Sie können immer noch laufen:

git checkout abcdefghi

git checkout -b

Wenn Ihre Organisation JIRA oder ein anderes ähnliches System verwendet, das an Git gebunden ist, können Sie die auf dem Ticket selbst angegebenen Commits finden und auf die Links zu den Codeänderungen klicken. Github löscht den Zweig, hat aber noch die Commits für das Rosinenpicken verfügbar.

  1. finde coimmit id heraus

    Git Reflog

  2. Wiederherstellung der lokalen Verzweigung, die Sie versehentlich gelöscht haben

    git branch need-recover-branchname commitId

  3. Drücken Sie need-recover-branch-name erneut, wenn Sie zuvor auch remote Branch gelöscht haben

    git push Herkunft Need-Recover-Branch-Name

Es mag zu vorsichtig erscheinen, aber ich ziehe häufig eine Kopie von dem, woran ich gearbeitet habe, bevor ich Änderungen an der Quellcodeverwaltung vornehme. In einem Gitlab-Projekt, an dem ich gerade arbeite, habe ich kürzlich einen Remote-Zweig aus Versehen gelöscht, den ich nach dem Zusammenführen einer Zusammenführungs-Anfrage behalten wollte. Es stellte sich heraus, alles was ich tun musste, um es mit der Commit-Geschichte zurück zu bekommen, war erneut Push. Die Zusammenführungsanfrage wurde immer noch von Gitlab verfolgt, so dass immer noch die blaue “Zusammengeführt” -Etikette rechts neben der Verzweigung angezeigt wird. Ich habe immer noch meinen lokalen Ordner gezippt, falls etwas Schlimmes passiert ist.