Umbenennen von Dateien in Git umbenennen

Ich habe gelesen, dass Sie beim Umbenennen von Dateien in Git alle Änderungen festschreiben, Ihre Umbenennung durchführen und dann Ihre umbenannte Datei bereitstellen sollten. Git erkennt die Datei anhand des Inhalts, anstatt sie als neue nicht verfolgte Datei zu betrachten, und behält den Änderungsverlauf bei.

Als ich heute Abend genau das tat, kehrte ich jedoch zurück git mv.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Benennen Sie mein Stylesheet im Finder von iphone.cssnach ummobile.css

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    css/iphone.css
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   css/mobile.css

Git glaubt nun, ich hätte eine CSS-Datei gelöscht und eine neue hinzugefügt. Nicht was ich will, lass uns die Umbenennung rückgängig machen und git die Arbeit machen lassen.

> $ git reset HEAD .
Unstaged changes after reset:
M   css/iphone.css
M   index.html

Zurück zu meinem Ausgangspunkt.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Verwenden wir git mvstattdessen.

> $ git mv css/iphone.css css/mobile.css
> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    css/iphone.css -> css/mobile.css
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   index.html
#

Sieht so aus, als wären wir gut. Warum hat git die Umbenennung beim ersten Mal nicht erkannt, als ich Finder verwendet habe?

Für git mvdie Handbuchseite heißt es

Der Index wird nach erfolgreichem Abschluss aktualisiert, […]

Sie müssen den Index also zunächst selbst aktualisieren (mithilfe von git add mobile.css). Es werden jedoch
git status weiterhin zwei verschiedene Dateien angezeigt

$ git status
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       new file:   mobile.css
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    iphone.css
#

Sie können eine andere Ausgabe erhalten, indem Sie ausführen git commit --dry-run -a, was zu dem führt, was Sie erwarten:

Tanascius@H181 /d/temp/blo (master)
$ git commit --dry-run -a
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       renamed:    iphone.css -> mobile.css
#

Ich kann Ihnen nicht genau sagen, warum wir diese Unterschiede zwischen git statusund sehen
git commit --dry-run -a, aber hier ist ein Hinweis von Linus :

git , dass es nicht auch egal über die ganze „Umbenennungs detection“ intern und alle Commits Sie mit Umbenennungen getan haben , sind völlig unabhängig von den Heuristiken wir dann verwenden , zeigen die Umbenennungen.

A dry-runverwendet die realen Umbenennungsmechanismen, während a dies git statuswahrscheinlich nicht tut.

Sie müssen die beiden geänderten Dateien zum Index hinzufügen, bevor git sie als Verschiebung erkennt.

Der einzige Unterschied zwischen mv old newund git mv old newbesteht darin, dass der Git MV auch die Dateien zum Index hinzufügt.

mv old newdann git add -Ahätte es auch geklappt.

Beachten Sie, dass Sie nicht nur verwenden können, git add .da dadurch keine Entfernungen zum Index hinzugefügt werden.

Siehe Unterschied zwischen "git add -A" und "git add".

Am besten probieren Sie es selbst aus.

mkdir test
cd test
git init
touch aaa.txt
git add .
git commit -a -m "New file"
mv aaa.txt bbb.txt
git add .
git status
git commit --dry-run -a

Jetzt zeigen git status und git commit --dry-run -a zwei verschiedene Ergebnisse an, wobei git status bbb.txt als neue Datei anzeigt / aaa.txt gelöscht wird und die Befehle --dry-run die tatsächliche Umbenennung anzeigen.

~/test$ git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   bbb.txt
#
# 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:    aaa.txt
#


/test$ git commit --dry-run -a

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    aaa.txt -> bbb.txt
#

Jetzt checken Sie ein.

git commit -a -m "Rename"

Jetzt können Sie sehen, dass die Datei tatsächlich umbenannt wurde und was im Git-Status angezeigt wird, falsch ist.

Moral der Geschichte: Wenn Sie nicht sicher sind, ob Ihre Datei umbenannt wurde, geben Sie ein "git commit --dry-run -a" aus. Wenn angezeigt wird, dass die Datei umbenannt wurde, können Sie loslegen.

Für Git 1.7.x haben die folgenden Befehle für mich funktioniert:

git mv css/iphone.css css/mobile.css
git commit -m 'Rename folder.' 

Git add musste nicht hinzugefügt werden, da sich die Originaldatei (dh css / mobile.css) bereits zuvor in den festgeschriebenen Dateien befand.

du musst git add css/mobile.cssdie neue datei und git rm css/iphone.cssdamit weiß git davon. dann wird die gleiche Ausgabe in angezeigtgit status

Sie können es deutlich in der Statusausgabe sehen (der neue Name der Datei):

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)

und (der alte Name):

# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)

Ich denke, hinter den Kulissen git mvgibt es nichts weiter als ein Wrapper-Skript, das genau das tut: Löschen Sie die Datei aus dem Index und fügen Sie sie unter einem anderen Namen hinzu

Lassen Sie uns über Ihre Dateien aus der Git-Perspektive nachdenken.

Denken Sie daran, dass git keine Metadaten zu Ihren Dateien verfolgt

Ihr Repository hat (unter anderem)

$ cd repo
$ ls
...
iphone.css
...

und es ist unter git Kontrolle:

$ git ls-files --error-unmatch iphone.css &>/dev/null && echo file is tracked
file is tracked

Testen Sie dies mit:

$ touch newfile
$ git ls-files --error-unmatch newfile &>/dev/null && echo file is tracked
(no output, it is not tracked)
$ rm newfile

Wenn Sie das tun

$ mv iphone.css mobile.css

Aus Git-Perspektive,

• Es gibt keine iphone.css (sie wird gelöscht - Git warnt davor).
• Es gibt eine neue Datei mobile.css .
• Diese Dateien haben nichts miteinander zu tun.

Git berät also über bereits bekannte Dateien ( iphone.css ) und neue erkannte Dateien ( mobile.css ), jedoch nur, wenn sich Dateien im Index befinden oder HEAD git beginnt, deren Inhalt zu überprüfen.

Derzeit sind weder "iphone.css deletion" noch mobile.css im Index.

Fügen Sie dem Index das Löschen von iphone.css hinzu

$ git rm iphone.css

git sagt dir genau, was passiert ist: ( iphone.css wird gelöscht. Es ist nichts mehr passiert)

Fügen Sie dann die neue Datei mobile.css hinzu

$ git add mobile.css

Diesmal befinden sich sowohl das Löschen als auch die neue Datei im Index. Jetzt erkennt git, dass der Kontext identisch ist, und macht ihn als Umbenennung verfügbar. Wenn Dateien zu 50% ähnlich sind, wird dies als Umbenennung erkannt , sodass Sie mobile.css ein wenig ändern können, während der Vorgang als Umbenennung beibehalten wird .

Siehe dies ist reproduzierbar auf git diff. Jetzt, da Ihre Dateien im Index sind, müssen Sie verwenden --cached. Bearbeiten Sie mobile.css ein wenig, fügen Sie das zum Index hinzu und sehen Sie den Unterschied zwischen:

$ git diff --cached 

und

$ git diff --cached -M

-Mist die Option "Umbenennungen erkennen" für git diff. -Msteht für -M50%(50% oder mehr Ähnlichkeit lässt git es als Umbenennung ausdrücken), aber Sie können dies auf -M20%(20%) reduzieren, wenn Sie mobile.css häufig bearbeiten.

Schritt 1: Benennen Sie die Datei von oldfile in newfile um

git mv #oldfile #newfile

Schritt 2: Git Commit und Kommentare hinzufügen

git commit -m "rename oldfile to newfile"

Schritt 3: Drücken Sie diese Änderung auf Remote-Server

git push origin #localbranch:#remotebranch

Git erkennt die Datei am Inhalt und sieht sie nicht als neue, nicht verfolgte Datei

Dort bist du falsch gelaufen.

Erst nachdem Sie die Datei hinzugefügt haben, erkennt Git sie anhand des Inhalts.

Sie haben die Ergebnisse Ihres Finder-Zuges nicht inszeniert. Ich glaube, wenn Sie den Umzug über Finder und dann getan hätten git add css/mobile.css ; git rm css/iphone.css, würde git den Hash der neuen Datei berechnen und erst dann erkennen, dass die Hashes der Dateien übereinstimmen (und somit eine Umbenennung).

In Fällen, in denen Sie die Dateien wirklich manuell umbenennen müssen, z. Verwenden eines Skripts zum Batch-Umbenennen einer Reihe von Dateien, dann mit git add -A .für mich funktioniert.

Für Xcode-Benutzer: Wenn Sie Ihre Datei in Xcode umbenennen, wird das Ausweissymbol in Anhängen geändert. Wenn Sie ein Commit mit XCode durchführen, erstellen Sie tatsächlich eine neue Datei und verlieren den Verlauf.

Eine Problemumgehung ist einfach, muss jedoch vor dem Festschreiben mit Xcode durchgeführt werden:

1. Machen Sie einen Git-Status in Ihrem Ordner. Sie sollten sehen, dass die inszenierten Änderungen korrekt sind:

umbenannt in: Project / OldName.h -> Project / NewName.h umbenannt in: Project / OldName.m -> Project / NewName.m

1. Commit -m 'Namensänderung'

Kehren Sie dann zu XCode zurück, und Sie werden sehen, dass das Abzeichen von A nach M geändert wurde. Es ist sicher, weitere Änderungen bei der Verwendung von xcode vorzunehmen.