Uwzględnianie wielkości liter w Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Systemy plików w Windows i macOS są domyślnie niewrażliwe na wielkość liter (ale zachowują wielkość liter). Większość systemów plików w Linuksie jest wrażliwa na wielkość liter. Git powstał pierwotnie jako system kontroli wersji jądra systemu Linux, więc nic dziwnego, że rozróżnia wielkość liter.

Podczas gdy wiele problemów z systemem operacyjnym rozróżniającym wielkość liter zostało rozwiązanych w oprogramowaniu Git dla systemu Windows, pozostaje kilka niedociągnięć.

Nazwy plików i folderów

W systemie Linux wyewidencjonowanie repozytorium Git zawierającego zarówno "File.txt" i "file.txt" nie ma problemu. Są to odrębne nazwy plików. W systemach Windows i macOS wyewidencjonowanie obu plików spowoduje, że drugi plik nadpisze pierwszy. Jeśli dwa foldery różnią się tylko wielkością liter, ich zawartości zostaną pomieszane w systemach plików niewrażliwych na wielkość liter.

Rozwiązywanie konfliktów przypadków

Jednym ze sposobów rozwiązania repozytorium z tym problemem jest sprawdzenie go w środowisku z uwzględnieniem wielkości liter. Zmień nazwy plików i folderów, aby nie były już w konflikcie, a następnie wypchnij te zmiany do repozytorium. podsystem Windows dla systemu Linux jest jednym z takich środowisk. Innym podejściem jest użycie polecenia git mv -f <conflicting name> <non-conflicting name> dla każdego konfliktu, uważając na dokładne użycie wielkich liter w obu nazwach plików.

Unikanie konfliktów przypadków

Warto unikać tworzenia tej sytuacji w pierwszej kolejności. Usługa Azure Repos oferuje ustawienie wymuszania wielkości liter , aby zapobiec wypchnięciom, co doprowadziłoby do tej sytuacji. W przypadku deweloperów wdrożenie nawyku używania uzupełniania tabulatorów do zatwierdzania plików również pomoże. Ponieważ zarówno system Windows, jak i macOS zachowują wielkość liter, zapewni to, że wewnętrzne elementy usługi Git będą widzieć dokładnie taką samą wielkość liter, jaką używa system plików.

Nazwy gałęzi i tagów

Można utworzyć dwie gałęzie lub tagi (znane jako "refs"), które różnią się tylko wielkością liter. Wewnętrzne mechanizmy Git, jak również usługi Azure DevOps Services/TFS, traktują je jako dwa oddzielne referencje. Na maszynie użytkownika usługa Git używa systemu plików do przechowywania refs. Pobieranie danych i inne operacje zaczynają się nieudawać z powodu niejednoznaczności. Każdy element ref jest reprezentowany przez mały plik, a jeśli nazwa ref zawiera / znaki, części przed finałem / są reprezentowane przez foldery.

Jednym z prostych sposobów uniknięcia problemów jest zawsze używanie nazw gałęzi i tagów z małymi literami. Jeśli masz już dwa gałęzie lub tagi z tym problemem, możesz rozwiązać ten problem w internetowym interfejsie użytkownika usługi Azure Repos.

Naprawianie nazw gałęzi

Na stronie gałęzi przejdź do powiązanego komitu. W menu kontekstowym wybierz pozycję "Nowa gałąź". Nadaj gałęzi nową nazwę, która nie ma konfliktu przypadków. Wróć do strony gałęzi i usuń gałąź powodującą konflikt.

Naprawianie nazw tagów

Kroki naprawiania nazwy tagu są podobne do gałęzi. Na stronie tagów przejdź do zatwierdzenia z tagiem. W menu kontekstowym wybierz pozycję "Utwórz tag". Nadaj tagowi nową nazwę, która nie ma konfliktu przypadków. Wróć do strony tagów i usuń tag powodujący konflikt.