Z tego, co rozumiem, Git tak naprawdę nie musi śledzić operacji zmiany nazwy pliku / przenoszenia / kopiowania, więc jaki jest prawdziwy cel git mv ? Strona podręcznika nie jest specjalnie opisowa ...
Czy to jest przestarzałe? Czy to polecenie wewnętrzne, które nie jest przeznaczone dla zwykłych użytkowników?
Odpowiedzi:
git mv oldname newname
jest po prostu skrótem dla:
mv oldname newname
git add newname
git rm oldname
tzn. automatycznie aktualizuje indeks zarówno starych, jak i nowych ścieżek.
mv oldname newname; git add newname; git rm oldname, również się nie powiedzie git mv oldname newname(zobacz tę odpowiedź ).
git mvróżni się nieco od tego mv oldname newname; git add newname; git rm oldname, że jeśli dokonałeś zmian w pliku przed git mvjego wprowadzeniem, zmiany te nie zostaną wprowadzone do czasu, aż pojawi git addsię nowy plik.
Git ma polecenie zmiany nazwy
git mv, ale to tylko wygoda. Efekt jest nie do odróżnienia od usunięcia pliku i dodania innego o innej nazwie i tej samej treści
git mvpodejściem ręcznym? To nie jest oczywiste z git help mv.
Git próbuje zgadnąć, co próbujesz zrobić. Dokłada wszelkich starań, aby zachować nieprzerwaną historię. Oczywiście nie jest idealny. Dzięki git mvtemu możesz wyrazić swoją intencję i uniknąć błędów.
Rozważ ten przykład. Zaczynając od pustego repozytorium,
git init
echo "First" >a
echo "Second" >b
git add *
git commit -m "initial commit"
mv a c
mv b a
git status
Wynik:
# On branch master
# 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)
#
# modified: a
# deleted: b
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# c
no changes added to commit (use "git add" and/or "git commit -a")
Autodetekcja nie powiodła się :( A może to?
$ git add *
$ git commit -m "change"
$ git log c
commit 0c5425be1121c20cc45df04734398dfbac689c39
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:24:56 2013 -0400
change
i wtedy
$ git log --follow c
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:24:56 2013 -0400
change
commit 50c2a4604a27be2a1f4b95399d5e0f96c3dbf70a
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:24:45 2013 -0400
initial commit
Teraz spróbuj zamiast tego (pamiętaj, aby usunąć .gitfolder podczas eksperymentowania):
git init
echo "First" >a
echo "Second" >b
git add *
git commit -m "initial commit"
git mv a c
git status
Na razie w porządku:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: a -> c
git mv b a
git status
Teraz nikt nie jest idealny:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: a
# deleted: b
# new file: c
#
Naprawdę? Ale oczywiście...
git add *
git commit -m "change"
git log c
git log --follow c
... a wynik jest taki sam jak powyżej: --followpokazuje tylko pełną historię.
Teraz zachowaj ostrożność przy zmianie nazwy, ponieważ każda z opcji może nadal wywoływać dziwne efekty . Przykład:
git init
echo "First" >a
git add a
git commit -m "initial a"
echo "Second" >b
git add b
git commit -m "initial b"
git mv a c
git commit -m "first move"
git mv b a
git commit -m "second move"
git log --follow a
commit 81b80f5690deec1864ebff294f875980216a059d
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:35:58 2013 -0400
second move
commit f284fba9dc8455295b1abdaae9cc6ee941b66e7f
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:34:54 2013 -0400
initial b
Porównaj to z:
git init
echo "First" >a
git add a
git commit -m "initial a"
echo "Second" >b
git add b
git commit -m "initial b"
git mv a c
git mv b a
git commit -m "both moves at the same time"
git log --follow a
Wynik:
commit 84bf29b01f32ea6b746857e0d8401654c4413ecd
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:37:13 2013 -0400
both moves at the same time
commit ec0de3c5358758ffda462913f6e6294731400455
Author: Sergey Orshanskiy <*****@gmail.com>
Date: Sat Oct 12 00:36:52 2013 -0400
initial a
Ups ... Teraz historia wraca do początkowej a zamiast początkowej b , co jest złe. Więc kiedy wykonaliśmy dwa ruchy na raz, Git był zdezorientowany i nie śledził poprawnie zmian. Nawiasem mówiąc, w moich eksperymentach to samo stało się, gdy usunąłem / utworzyłem pliki zamiast ich używać git mv. Postępuj ostrożnie; Zostałeś ostrzeżony...
Jak mówi @Charles, git mv jest to skrót.
Prawdziwe pytanie brzmi: „Inne systemy kontroli wersji (np. Subversion i Perforce) traktują specjalnie nazwy plików. Dlaczego Git?”
Linus wyjaśnia na http://permalink.gmane.org/gmane.comp.version-control.git/217 charakterystycznym taktem:
Proszę, przestań to badziewie. Git śledzi dokładnie to , co się liczy, a mianowicie „kolekcje plików”. Nic innego nie jest istotne, a nawet myślenie, że jest to istotne, ogranicza jedynie twoje spojrzenie na świat. Zauważ, że pojęcie „adnotacji” CVS zawsze nieuchronnie ogranicza sposób, w jaki ludzie go używają. Myślę, że to zupełnie bezużyteczne badziewie i opisałem coś, co moim zdaniem jest milion razy bardziej przydatne, i wszystko to wypadło dokładnie dlatego, że nie ograniczam mojego myślenia do niewłaściwego modelu świata.
Jest jeszcze jedno zastosowanie, którego git mvnie wspomniałem powyżej.
Od czasu odkrycia git add -p(tryb łatki git add; patrz http://git-scm.com/docs/git-add ), lubię go używać do sprawdzania zmian podczas dodawania ich do indeksu. Tak więc mój przepływ pracy staje się (1) pracą nad kodem, (2) przeglądaniem i dodawaniem do indeksu, (3) zatwierdzaniem.
Jak git mvpasuje? Jeśli przenosisz plik bezpośrednio, wtedy używając git rmi git add, wszystkie zmiany zostaną dodane do indeksu, a użycie git diff do przeglądania zmian jest mniej łatwe (przed zatwierdzeniem). git mvJednak użycie dodaje nową ścieżkę do indeksu, ale nie wprowadza zmian w pliku, co pozwala git diffi git add -pdziała jak zwykle.
Istnieje niszowy przypadek, w którym git mvpozostaje bardzo przydatny: gdy chcesz zmienić obudowę nazwy pliku w systemie plików bez rozróżniania wielkości liter. Zarówno APFS (Mac), jak i NTFS (Windows) domyślnie nie rozróżniają wielkości liter (ale zachowują wielkość liter).
greg.kindel wspomina o tym w komentarzu do odpowiedzi CB Baileya.
Załóżmy, że pracujesz na komputerze Mac i masz plik Mytest.txtzarządzany przez git. Chcesz zmienić nazwę pliku na MyTest.txt.
Możesz spróbować:
$ mv Mytest.txt MyTest.txt
overwrite MyTest.txt? (y/n [n]) y
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
O jej. Git nie potwierdza, że doszło do jakichkolwiek zmian w pliku.
Państwo mogłoby obejść się przez zmianę nazwy pliku całkowicie następnie zmieniając jego nazwę z powrotem:
$ mv Mytest.txt temp.txt
$ git rm Mytest.txt
rm 'Mytest.txt'
$ mv temp.txt MyTest.txt
$ git add MyTest.txt
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: Mytest.txt -> MyTest.txt
Hurra!
Lub możesz zaoszczędzić sobie tyle trudu, używając git mv:
$ git mv Mytest.txt MyTest.txt
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: Mytest.txt -> MyTest.txt