Git erkennt umbenannte und geänderte Paketdateien nicht

Ich hatte eine Java-Datei namens package/old/myfile.java. Ich hatte diese Datei über Git übergeben. Ich habe dann mein Paket umbenannt in new Also meine Datei war drin package/new/myfile.java.

Ich möchte diese Dateiumbenennung (und Inhaltsänderungen) jetzt an git übertragen.

Wenn ich es tue git status Ich bekomme

# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    package/old/myfile.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       package/new/myfile.java

ich habe es versucht adddas neue und rming das Alte und umgekehrt, ich bekomme immer

$ git status
# On branch develop
# Changes to be committed: 
#        delete:    package/old/myfile.java
#        new file:  package/new/myfile.java

Ich kann nicht mv old new weil die alte Datei nicht existiert und ich bekomme bad source Error.

Kann ich noch etwas versuchen?

Ich habe einige der Mehrfachantworten auf SO für ähnliche Probleme ausprobiert, aber sie haben nicht funktioniert.

Das entsprechenden Abschnitt von dem Git-Buch erklärt dies.

Im Gegensatz zu vielen anderen VCS-Systemen verfolgt Git Dateibewegungen nicht explizit. Wenn Sie eine Datei in Git umbenennen, werden in Git keine Metadaten gespeichert, die darauf hinweisen, dass Sie die Datei umbenannt haben. Git ist jedoch ziemlich schlau, wenn es darum geht, das im Nachhinein herauszufinden – wir werden uns etwas später mit der Erkennung von Dateibewegungen befassen.

Das bedeutet, dass Git nicht weiß, dass es sich um eine Verschiebung handelt, wenn Sie eine Datei verschieben und dann wesentliche Änderungen vornehmen. Es wird eine Datei gelöscht und eine neue Datei erstellt, da die neue Datei nicht wie die alte aussieht. Um diese Leute oft herumzukommen git mv Dateien, übertragen Sie die Verschiebung und nehmen Sie dann Änderungen vor. In Ihrer Situation können Sie tun

git reset # Move changes from index to working copy
git checkout package/old/myfile.java # Undo delete
git mv package/old/myfile.java package/new/myfile.java # Move file

Verschiebe die Datei zurück, übertrage sie dann und setze die eigentliche Verschiebung in einen separaten Commit. Git zeichnet Bewegungen (oder Umbenennungen) nicht als solche auf, kann sie aber nachträglich anhand des Inhalts erkennen. Wenn sich der Inhalt ändert, kann es die Bewegung nicht richtig erkennen. Daher ist es üblich, Moves und Changes in zwei Commits aufzuteilen.

Befehle zum Implementieren von @Nevik Rehnels Vorschlag von zwei Commits durch Umschreiben des Verlaufs, um die Datei zu verschieben, bevor sie bearbeitet wird:

Ausgangszustand:

• Ihr letzter Commit umfasst sowohl eine Verschiebung als auch eine Änderung an einer Datei und git log --follow newpath zeigt die Datei als neu erstellt im letzten Commit an

Schritte:

• Markieren Sie Ihren aktuellen Status git tag working_code
• Starten Sie eine interaktive Rebase, um den Verlauf zu bearbeiten: git rebase -i HEAD~2
  • Ändern Sie im angezeigten Editor “Pick” in der ersten Zeile in “Edit”, speichern und beenden Sie.
• Sie bearbeiten jetzt den Verlauf kurz vor Ihrem Commit
• Erstellen Sie die Verschiebung als eigenen Commit
  • git mv oldpath newpath
  • Das Verzeichnis, das den neuen Dateispeicherort enthalten soll, muss existieren; Möglicherweise müssen Sie mkdir es zuerst
  • (optional) Bearbeiten Sie die Datei mit allen kleinen Änderungen, die für die Dateiumbenennung erforderlich sind (z. B. in Java: Klassenname und/oder Paket- und Importzeilen) – Vermeiden Sie andere Änderungen Git erkennt diese aufgrund der Ähnlichkeit als dieselbe Datei
  • git add . und überprüfe das git status zeigt jetzt: renamed: oldpath -> newpath
  • git commit -m "Rename oldpath newpath"
• git rebase --continue
  • Sie sollten einen Konflikt auf newpath bekommen. Stellen Sie die Datei wieder her mit git checkout working_code newpath
  • Vervollständigen Sie die Neubasis: git rebase --continue
• Überprüfen Sie, dass git log --follow newpath zeigt die komplette Historie