Zgodność międzyplatformowa usługi Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Systemy plików Windows, macOS i Linux mają ograniczenia i zachowania, których jedna lub więcej inna platforma nie zawsze obsługuje. Ponieważ usługa Git to technologia międzyplatformowa, deweloper może wykonać zatwierdzenie zawierające pliki lub foldery, które mają niezgodne nazwy z systemem plików innej platformy. Ochrona repozytorium przed tą niezgodnością jest ważna, ponieważ deweloperzy na innych platformach mogą nieświadomie pobrać zatwierdzenie, które zepsuje ich katalogi robocze z powodu nieobsługiwanych nazw plików lub ścieżek.

Usługa Azure Repos oferuje trzy ustawienia zgodności międzyplatformowej, które chronią repozytorium przed pushowaniem zatwierdzeń niezgodnych z co najmniej jedną platformą. Te ustawienia są związane z następującymi ograniczeniami dotyczącymi systemów plików:

• Ważność wielkości liter
• Ograniczenia dotyczące nazw plików i folderów
• Ograniczenia długości ścieżki

Czułość na wielkość liter

Systemy plików w Windows i macOS są domyślnie niewrażliwe na wielkość liter, ale zachowują oryginalną ich wielkość. Większość systemów plików Linux rozróżnia wielkość liter. Git został pierwotnie stworzony jako system kontroli wersji jądra Linux, więc rozróżnia wielkość liter.

Chociaż Git dla systemu Windows rozwiązuje wiele problemów z systemem operacyjnym niewrażliwym na wielkość liter, pozostaje kilka dziwactw.

Nazwy plików i folderów

W systemie Linux wyewidencjonowanie repozytorium Git zawierającego zarówno File.txt, jak i file.txt nie ma problemu. Są to odrębne nazwy plików. W systemach Windows i macOS wyewidencjonowanie obu plików powoduje, że drugi zastępuje pierwszy. Jeśli dwa foldery różnią się jedynie wielkością liter, ich zawartość jest mieszana w systemach plików, które nie rozróżniają wielkości liter.

Istnieją dwa sposoby naprawiania repozytorium, które zawiera konflikty przypadków:

• Zapoznaj się z repozytorium 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.
• Użyj polecenia git mv -f <conflicting name> <non-conflicting name> dla każdego konfliktu. Należy zachować ostrożność, aby używać poprawnej wielkości liter w obu nazwach plików.

Warto unikać tworzenia konfliktów przypadków w pierwszej kolejności. Usługa Azure Repos oferuje ustawienie wymuszania przypadków, aby zapobiec wypchnięciom, które doprowadzą do tej sytuacji. Dla deweloperów, przyjęcie nawyku używania uzupełniania poprzez tabulator do zatwierdzania plików również pomoże. Ponieważ zarówno system Windows, jak i macOS zachowują wielkość liter, te podejścia zapewniają, że wewnętrzne elementy usługi Git będą widzieć dokładnie taką samą wielkość liter, z jaką korzysta 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 oraz Azure DevOps Services i Azure DevOps Server traktują je jako dwa oddzielne odwołania referencyjne. Na komputerze użytkownika Git używa systemu plików do przechowywania referencji. Pobieranie danych i inne operacje zaczynają się nieudawać z powodu niejednoznaczności.

Mały plik reprezentuje każdy element ref. Jeśli nazwa ref zawiera znaki ukośnika (/), foldery reprezentują części przed ostatnim ukośnikiem.

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, które mają ten problem, możesz je rozwiązać w internetowym interfejsie użytkownika usługi Azure Repos.

Aby naprawić nazwy gałęzi:

1. Na stronie gałęzi przejdź do powiązanego commita.
2. W menu skrótów wybierz pozycję Nowa gałąź.
3. Nadaj gałęzi nową nazwę, która nie ma konfliktu przypadków.
4. Wróć do strony z gałęziami i usuń konfliktową gałąź.

Aby naprawić nazwy tagów:

1. Na sekcji tagów przejdź do zatwierdzenia opisanego tagiem.
2. W menu skrótów wybierz pozycję Utwórz tag.
3. Nadaj tagowi nową nazwę, która nie ma konfliktu przypadków.
4. Wróć do strony tagów i usuń tag powodujący konflikt.

Ograniczenia dotyczące ścieżki i nazwy pliku

Systemy operacyjne Windows, macOS i Linux mają różne ograniczenia dotyczące nazw plików i ścieżek. Te ograniczenia ograniczają nazwy plików lub folderów, które mogą powodować problemy dla zespołów korzystających z usługi Git na wielu platformach.

Załóżmy na przykład, że deweloper na jednej platformie zatwierdza zmianę udostępnionego repozytorium zawierającego nazwę pliku lub długość ścieżki, która jest nieprawidłowa na innej platformie. Później inny deweloper próbuje wyewidencjonować to zatwierdzenie na platformie, na której zawartość jest nieprawidłowa. Taka sytuacja prowadzi do uszkodzenia katalogu roboczego, co może skutkować zniszczeniem repozytorium poprzez uszkodzone dane.

Usługa Azure Repos oferuje ustawienia repozytorium, które blokują wypchnięcia zawierające zmiany naruszające co najmniej jedno z następujących ograniczeń.

Tabela referencyjna dla nazw plików i ścieżek

Ograniczenia/platformy	Windows	macOS	Linux
Ograniczenia nazw plików	nazwy plików zarezerwowanych: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Nazwy plików zarezerwowanych, po których następuje . Zastrzeżone znaki: \ / : * ? " < > Nazwy plików, które kończą się . lub białym znakiem	Nazwy plików, które kończą się /	Nazwy plików, które kończą się /
Ograniczenia długości ścieżki	Ścieżki w systemie Windows mają maksymalną długość 260 znaków (w tym zakończenie zerowe). W przypadku katalogów z platformą .NET w pełni kwalifikowana nazwa pliku musi być mniejsza niż 260 znaków, a nazwa katalogu musi być mniejsza niż 248 znaków.	Nazwy plików są ograniczone do 255 znaków. Maksymalna długość ścieżek w HFS+ jest udokumentowana jako nieograniczona, chociaż niektóre wersje systemu macOS ograniczają ścieżki do 1,016 znaków. Niektóre systemy plików obsługują wartość 1016 jako maksymalną ścieżkę.	Nazwy plików są ograniczone do 255 znaków. Maksymalna długość ścieżki wynosi 4096.

Obsługa kodowania

Firma Microsoft dodała obsługę kodowania UTF-16 i UTF-32 za pośrednictwem punktu końcowego internetowego push. Ta obsługa oznacza, że zachowujemy typ kodowania, więc nie trzeba ponownie pisać plików jako UTF-8. Podczas próby zapisania pliku przez internet, który nie jest zakodowany w formacie UTF (ponieważ internet obsługuje tylko kodowanie UTF), zostanie wyświetlone ostrzeżenie.

Poniższy zrzut ekranu przedstawia przykład okna dialogowego wyświetlanego podczas wprowadzania zmian kodowania przy użyciu wypychania internetowego.