Nazwa odgałęzienia Git - wielkość liter jest niewrażliwa?

Question

Jestem nowym użytkownikiem git i niedawno otrzymałem nieaktualne repozytorium git.

Jest to oryginalny stan (wyjście przez git show-oddział):

! [cr232] CR 232 Release 
     * [dev] Style Changes 
--------------- 
     * [dev] Style Changes 
     * [dev^] SMS 5.4 
     * [dev~2] Logo Change 
     * [dev~3] SMS 5.3 
     * [dev~4] SMS 5.2 
     * [dev~5] SIT R-0.3.3 EDW SMS Layers 
     * [dev~6] SIT Release R 0.3.0 
     +* [cr232] CR 232 Release 
     +* [cr232^] Dashboard Fix 
     +* [cr232~2] Release for system testing 

Zauważ, że tam jest oddział zwany „dev” w tym momencie. Zwróć uwagę, że wyróżnione są pewne odniesienia do dev (tj. Dev, dev ^, dev ~ 2 itd.).

Dla mojego celu rozwoju, starałem się wymyślić oddział o nazwie "DEV", cały kapitał.

Więc poszedł do przodu i utworzyć nowy oddział git branch (DEV) i teraz działa git show-oddział -date zamówienie:

! [DEV] Style Changes 
    ! [cr232] CR 232 Release 
     * [dev] Style Changes 
--------------- 
     * [DEV] Style Changes 
     * [DEV^] SMS 5.4 
     * [DEV~2] Logo Change 
     * [DEV~3] SMS 5.3 
     * [DEV~4] SMS 5.2 
     * [DEV~5] SIT R-0.3.3 EDW SMS Layers 
     * [DEV~6] SIT Release R 0.3.0 
     +* [cr232] CR 232 Release 
     +* [cr232^] Dashboard Fix 
     +* [cr232~2] Release for system testing 

Należy zauważyć, że zarówno dev DEV i są wymienione jako oddział. Zauważ także, że w piątej linii odniesienia do dev zmieniły się teraz na DEV (tj. DEV, DEV ^, DEV ~ 2 itd.).

Co to jest wiersz 5 wyjścia? Spodziewam się, że pozostanie to "dev", zamiast być zmienionym na "DEV", ponieważ opisy obok niego odnoszą się do opisu starej pracy w gałęzi "dev".

staram się wrócić do tego, jak to było przez modyfikację nazwy oddziału DEV DV (bieganie git branch -m DEV DV) i przedstawiający gałąź teraz wyglądać następująco:

! [DV] Style Changes 
    ! [cr232] CR 232 Release 
     * [dev] Style Changes 
--------------- 
     * [DV] Style Changes 
     * [DV^] SMS 5.4 
     * [DV~2] Logo Change 
     * [DV~3] SMS 5.3 
     * [DV~4] SMS 5.2 
     * [DV~5] SIT R-0.3.3 EDW SMS Layers 
     * [DV~6] SIT Release R 0.3.0 
     +* [cr232] CR 232 Release 
     +* [cr232^] Dashboard Fix 
     +* [cr232~2] Release for system testing 

Należy zauważyć, że gałąź zawiera teraz DV i dev. Zauważ również, że odniesienia do piątej linii do dev zmieniły się teraz na DV (tj. DV, DV ^, DV ~ 2 itd.).

Czy jest jakiś sposób, aby powrócić do stanu oryginalnego w okresie odniesień DV? Czy git wpadł w zakłopotanie i przemianował moje historyczne informacje na podobny oddział, który różni się tylko przypadkiem kapitałowym?

Proszę pomóc, jak mogę to naprawić. Dzięki hałdy

Answer 1

Więc poszedł do przodu i utworzyć nowy oddział (GIT oddziału DEV)

został utworzony nowy oddział DEV kiedy byłaś na gałęzi dev. Tak więc DEV i dev to dwie gałęzie, które wskazują na to samo zatwierdzenie. Po zmianie nazwy na DEV na DV, teraz DV i dev to dwie gałęzie, które wskazują ten sam commit.

Wszystko jest w porządku. Jeśli nie chcesz, aby Cię niepokoiło, możesz po prostu uruchomić git branch -d DV, aby usunąć gałąź DV. Jeśli rzeczywiście chcesz stworzyć nowy oddział, lepiej postępować zgodnie z pewną zasadą nazewnictwa, która nie będzie mylić Ciebie i innych.

Nigdy nie używałem git show-branch. git log --oneline --all --graph --decorate=full rysuje wyraźną grafikę dziennika.

Answer 2

Odbieranie tylko pytanie w temacie, nie zwracając nic o git show-branch (like ElpieKay, nigdy nie faktycznie korzysta git show-branch; wydaje głównie mis-informacyjny):

nazwy

nazwy-a gałąź Git tag oraz wszystkie inne referencje nazwy, jak Git nazywa je - były pierwotnie przeznaczone, aby rozróżniać wielkie i małe litery.

Wszystko to działa doskonale na komputerach z systemem Linux/Unix, gdzie na początku kodu Git jest rozróżniana wielkość liter. Kiedy Git przechowuje nazwy oddziałów w systemie plików jako nazwy plików (które to robi tylko czasami), system plików również rozróżnia duże i małe litery.

Czasamikończy się niepowodzeniem w systemach Windows i niektórych systemach MacOS. W szczególności nie powiedzie się, gdy Git przechowuje odwołania w poszczególnych plikach, których nazwy pochodzą od nazwy referencyjnej, a nazwy tych plików nie rozróżniają wielkości liter (np. Zachowanie z zachowaniem wielkości liter, ale fałszowanie w trakcie dopasowywania nazw, a nawet przekształcanie wszystkiego w wielkie litery - tak jak w starym formacie FAT 8.3, ale możemy mieć nadzieję, że nie zrobi tego żaden nowoczesny system plików).

Jak wspomniano powyżej, Git nie zawsze przechowuje nazwy referencyjne jako nazwy plików. W rzeczywistości na początkowym klonie wszystkie nazwy znajdują się w jednym pliku o nazwie .git/packed-refs, , więc w tym momencie są są wielkość liter. Ale z czasem stają się one "niezapakowane", a następnie w niektórych systemach stają się składane.

Ponieważ czasami kończy się niepowodzeniem w niektórych systemach, najlepiej jest unikać używania wielu nazw referencyjnych, które różnią się tylko przypadkiem.

---

oczywiście od nowoczesnych systemów Unix/Linux, można teraz uzyskać dostęp do case-zachowaniu-ale-wielkości liter systemów plików, a Windows i MacOS można teraz powiedziano, aby nie zrobić sprawę -folding dla niektórych systemów plików. (Ale jeśli zmienisz ustawienia domyślne, spodziewaj się, że oprogramowanie przeznaczone dla twojego pudełka zawiedzie, ponieważ tak będzie, rzeczy takie jak Photoshop wewnętrznie próbują używać plików o nazwach foo i FOO i oczekują, że odniesie się do tego samego pliku!)

Ten spakowany plik referencyjny istnieje już od jakiegoś czasu, ale nie na zawsze, a bardzo wczesne wersje Gita mogą go nie używać. Wewnętrznie Git nabywa nowy "wtyczkowy interfejs nazw referencyjnych", a przyszłe wersje Git mogą nie używać tego pliku ani indywidualnych plików referencyjnych.

Generalnie tworzenie lub aktualizowanie odwołania powoduje powstanie rozpakowanego pliku referencyjnego. Uruchamianie git pack-refs --all spowoduje zastąpienie rozpakowanych odniesień zapakowanymi, przywracając pełną wielkość liter. Bez pakietu --all, git pack-refs tylko pakiety są już zapakowanymi referencjami, co w dużej mierze jest bezużytecznym trybem działania (było przeznaczone dla przypadku, który nie jest już używany).