Git konnte die Datei beim Pull-Vorgang nicht trennen - wie komme ich aus dem inkonsistenten Zustand des Repositorys heraus?

Question

Bei der Ausführung von "git pull" hat Git den Vorgang abgebrochen, da die Verknüpfung einer Datei, die überschrieben werden soll, nicht aufgehoben werden konnte, da ich vergessen habe, eine Anwendung zu schließen, in der diese Dateien gesperrt sind.

Wenn ich die Anwendung schließen und versuchen, „git pull“ erneut auszuführen und die folgende Fehlermeldung erhalten:

"Error: Your local changes to the following files would be overwritten by merge: ..." 

und

"Error: The following untracked working tree files would be overwritten by merge: ..." 

Offensichtlich git abgebrochen nur den Zug, ohne eine Rolle zu tun -back und denkt jetzt, dass die Änderungen, die gerade gezogen wurden, meine lokalen Änderungen sind.

Wie komme ich aus diesem Zustand heraus? Wir sprechen über viele Dateien, und bevor ich eine "git revert" mache, müsste ich manuell nach jeder Datei suchen, wenn es lokale Änderungen von meiner Seite gibt.

Hinweis: Wir verwenden Git in einem Client-Server-ähnlichen Setup, wo die verteilten Entwickler "Pull" und "Push & Commit" häufig zu einem zentralen Bitbucket-Repository.

Answer 1

Da keine der oben genannten Methoden für mich funktionierte, habe ich eine Prozedur verwendet, die nicht vollständig automatisch ist, sondern den Aufwand auf einige manuell ausgewählte Dateien reduziert (in meinem Fall 2 statt 50). mit

git pull       

Jetzt Kasse aus dem Versteck

Erste Stash alle Dateien (einschließlich untracked und ignoriert) mit

git stash save --all    

dann die Pull-Redo, dass zuvor versäumt, einfach alle Dateien zu überschreiben, die während des ersten Ziehens geändert wurden (kein Merge-Versuch):

Jetzt Ein Problem bleibt: Änderungen, die zwischen dem fehlgeschlagenen Pull und dem zweiten Pull auf dem Server vorgenommen wurden, werden jetzt überschrieben. Aber das sollten nur ein paar Dateien sein (wenn die Zeit zwischen den beiden "Pull" kurz war), und viel einfacher in der Liste der von Ihnen selbst vorgenommenen Änderungen zu identifizieren. Sie können sie einfach "zurücksetzen" (ich habe den Tortoise-GIT-Commit-Dialog verwendet), bevor ich das letzte Commit ausführte.

git commit 
git stash drop 

Answer 2

Versuchen

git reset --merge 
git fetch --all 
git reset --hard origin/master 

ODER Wenn Sie auf einem anderen Zweig sind

git reset --hard origin/your_branch 

Erläuterung:

git fetch die neueste von remote herunterlädt, ohne etwas zu fusionieren oder rebase zu versuchen.

Dann setzt die git reset den Master-Zweig auf das, was Sie gerade abgerufen haben. Die --hard Option ändert alle Dateien in Ihrem Arbeits Baum

die Dateien in origin/master übereinstimmen Bemerkens Es ist erwähnenswert, dass es möglich ist, durch die Schaffung einer Niederlassung von master vor dem Zurücksetzen aktuellen lokalen Commits zu halten:

git checkout master 
git branch new-branch-to-save-current-commits 
git fetch --all 
git reset --hard origin/master 

Answer 3

git reset --hard 

werden alle Dateien auf ihren engagierten Zustand aufgespürt zurückgesetzt.

git clean -df 

werden alle verbleibenden nicht geordneten, unignored Dateien gelöscht.

Dann können Sie den Zug wiederholen. Plain Merge wird es tun, Sie haben bereits den Abruf durchgeführt.

---

Ich bin ziemlich sicher, dass das Verhalten aufgrund eines Unterschieds in wie Windows Dateien funktionieren soll. Wenn Sie in Unixland eine Datei öffnen, wird der Verzeichniseintrag freigegeben. Der Fehler, den Sie sehen, passiert einfach nicht auf dem Unix-System; Die offene Datei würde vorübergehend werden und so lange existieren, wie sie für einen Prozess offen blieb. Es gibt auch Nachteile auf der Unix-Art, Sie sehen einen Nachteil der Windows-Art. Die Problemumgehung ist einfach genug, zurücksetzen und sauber sind ziemlich Ihre Baustelle Cleanup Crew. Es ist ehrenvolle Arbeit, lerne sie kennen, sie kennen ihre Sachen.