Meine Commits wurden in ein anderes Projekt kopiert und meine Tags wurden verschoben.

Question

Ich machte ein Chaos mit meinem Git-Repository, indem ich die entfernte Adresse fälschlicherweise mit der eines anderen Projekts änderte.

Das Ergebnis ist jetzt, dass alle meine Commits von einem Projekt auf das andere Projekt mit genau der gleichen ID kopiert wurden.

Plus alle Beschriftungen aus dem ursprünglichen Projekt verschwanden magisch nur im zweiten Projekt gefunden werden. Seltsam ist, dass ich sie nur sehen kann, wenn ich die Tags suche, da sie nicht mit einem Zweig verbunden sind.

** Original-Projekt ** Wie Sie sehen die ID begehen kann, ist das gleiche in den beiden Projekten

zweite Projekt diese Tags mit ähnlichen verpflichten, dass Sie hier nicht ursprünglich sehen gehören zu diesem Projekt.

Was ich tun möchte, ist im Idealfall, alle Etiketten im ursprünglichen Projekt wiederherzustellen (also im Grunde zurück verschieben) und entfernen Sie alle diese zusätzlichen Commits aus dem zweiten Projekt (es gibt eine Menge, so ist der manuelle Prozess ein bisschen Zeitaufwendig).

Was ich seltsam gefunden, dass, wenn ich die Tags aus dem zweiten Projekt entfernen Sie dann auch die Commits auf magische Weise

Answer 1

keine vollständige Antwort, nur ein paar Erklärungen und Vorschläge zu verschwinden scheint, wie die situaion zu beheben.

Wenn beide Projekte Tags mit denselben Namen haben, sollten Sie beim Wiederherstellen ihres Status besondere Vorsicht walten lassen. Im Allgemeinen sollten alle aktiven Commits in git entweder durch ein anderes Commit oder Commit oder durch eine benannte Referenz, das heißt eine Verzweigung oder ein Tag, referenziert werden. Wenn Sie also eine Verzweigung oder ein Tag entfernen, das auf ein Commit verweist, besteht die Gefahr, dass die gesamte Kette von Commits verwaist wird und schließlich die Garbage Collection stattfindet. Selbst wenn einige Commits verschwunden sind, können sie für eine Weile von ihrem sha-1 erreichbar sein. Überprüfen Sie git reflog für sie.

Das erste, was Sie unter diesen Umständen tun sollten, ist, das beschädigte Repository in einen sauberen lokalen Ordner zu klonen. So behalten Sie zumindest das, was geblieben ist. Auch sollten Sie nach anderen Klonen des Repositories suchen (überprüfen Sie Ihre Festplatte (n) gründlich und fragen Sie Kollegen), wahrscheinlich enthalten diese Kopien korrekte Informationen über Tags und Zweige. Repository-Backups können in diesem Fall viel helfen, aber wer auf der Erde macht Backups vor ... Nur ein Scherz.

Sobald Sie ein Repo mit mindestens einigen korrekten Referenzen gefunden haben, können Sie diese Referenzen zwangsweise auf das defekte Remote-Repo sowie in die lokalen Kopien schieben. Verwenden Sie git push -f <tagname> aber tun Sie es mit besonderer Sorgfalt.

Ich bin mir nicht sicher, ob gitlab.com Backup-Dienste bietet, aber Sie können sie auch fragen, ob sie einen richtigen Snapshot des Repositorys haben. Natürlich, wenn sich Ihr Remote Repo auf gitlab.com befindet, nicht auf Ihrem eigenen Hosting.