Wie zwinge ich "git pull" dazu, lokale Dateien zu überschreiben?

Question

Wie erzwinge ich das Überschreiben von lokalen Dateien auf einer git pull ?

Das Szenario sieht folgendermaßen aus:

• Ein Teammitglied ändert die Vorlagen für eine Website, an der wir gerade arbeiten
• Sie fügen einige Bilder in das Verzeichnis images ein (vergessen aber, sie unter der Versionskontrolle hinzuzufügen)
• Sie schicken mir die Bilder später per Post zu.
• Ich füge die Bilder unter der Versionskontrolle hinzu und schiebe sie zusammen mit anderen Änderungen auf GitHub
• Sie können keine Aktualisierungen von GitHub beziehen, weil Git ihre Dateien nicht überschreiben will.

Ich erhalte folgende Fehlermeldung:

Fehler: Die nicht verfolgte Arbeitsbaumdatei 'public/images/icon.gif' würde beim Zusammenführen überschrieben werden

Wie kann ich Git zwingen, sie zu überschreiben? Die Person ist ein Designer - normalerweise löse ich alle Konflikte von Hand, so dass der Server die neueste Version hat, die er nur noch auf seinem Computer aktualisieren muss.

Answer 1

Es sieht so aus, als ob es am besten ist, zuerst etwas zu tun:

git clean

So löschen Sie alle nicht verfolgten Dateien und fahren dann mit der üblichen git pull ...

Answer 2

Warnung: Wenn Sie in Ihrer Gitignore-Datei Verzeichnis/*-Einträge haben, werden dadurch Ihre Dateien dauerhaft gelöscht.

Einige Antworten scheinen schrecklich zu sein. Schrecklich im Sinne dessen, was @Lauri passiert ist, als er dem Vorschlag von David Avsajanishvili folgte.

Stattdessen (git > v1.7.6):

git stash --include-untracked
git pull

Später können Sie den Versteckverlauf bereinigen.

Manuell, einer nach dem anderen:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}

Brutal, auf einen Schlag:

$ git stash clear

Natürlich, wenn Sie zu dem zurückkehren wollen, was Sie versteckt haben:

$ git stash list
...
$ git stash apply stash@{5}

Answer 3

Dieser Befehl kann hilfreich sein, um lokale Änderungen zu verwerfen:

git checkout <your-branch> -f

Und führen Sie dann eine Bereinigung durch (entfernt nicht verfolgte Dateien aus dem Arbeitsbaum):

git clean -f

Wenn Sie zusätzlich zu den nicht verfolgten Dateien auch die nicht verfolgten Verzeichnisse entfernen möchten:

git clean -fd

Answer 4

Das Einzige, was bei mir funktioniert hat, war:

git reset --hard HEAD~5

Dies führt Sie fünf Commits zurück und dann mit

git pull

Das habe ich herausgefunden, indem ich nachgeschaut habe wie man eine Git-Zusammenführung rückgängig macht .

Answer 5

Versuchen Sie es zunächst auf die übliche Weise:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!

Warnung : Die oben genannten Befehle können nur dann zu Daten-/Dateiverlusten führen, wenn Sie sie nicht übertragen haben! Wenn Sie sich nicht sicher sind, machen Sie zuerst ein Backup Ihres gesamten Repository-Ordners.

Ziehen Sie dann erneut daran.

Wenn das nicht hilft und Sie sich nicht um Ihre nicht verfolgten Dateien/Verzeichnisse kümmern (machen Sie vorsichtshalber zuerst ein Backup), versuchen Sie die folgenden einfachen Schritte:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again

Dadurch werden alle Git-Dateien ENTFERNT (mit Ausnahme von .git/ dir, wo Sie alle Commits haben) und ziehen Sie es erneut.

---

Warum git reset HEAD --hard in einigen Fällen scheitern könnte?

1. Benutzerdefinierte Regeln in .gitattributes file

   Mit eol=lf Regel in .gitattributes konnte dazu führen, dass Git einige Datei-Änderungen durch die Umwandlung von CRLF-Zeilenenden in LF in einigen Textdateien veränderte.

   Wenn das der Fall ist, müssen Sie diese CRLF/LF-Änderungen festschreiben (indem Sie sie in git status ), oder versuchen Sie es: git config core.autcrlf false sie vorübergehend zu ignorieren.

2. Dateisystem-Inkompatibilität

   Wenn Sie ein Dateisystem verwenden, das keine Berechtigungsattribute unterstützt. Ein Beispiel: Sie haben zwei Repositories, eines unter Linux/Mac ( ext3 / hfs+ ) und ein weiteres auf FAT32/NTFS basierendes Dateisystem.

   Wie Sie sehen, gibt es zwei verschiedene Arten von Dateisystemen, so dass dasjenige, das keine Unix-Berechtigungen unterstützt, grundsätzlich keine Dateiberechtigungen auf einem System zurücksetzen kann, das diese Art von Berechtigungen nicht unterstützt, also egal wie --hard Sie versuchen es, Git entdeckt immer einige "Änderungen".