Sdílet prostřednictvím


Kompatibilita Gitu pro různé platformy

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Systémy souborů Windows, macOS a Linux mají omezení a chování, které některé z ostatních platforem nepodporují vždy. Vzhledem k tomu, že Git je technologie pro různé platformy, je možné, že vývojář na jedné platformě potvrdí, že obsahuje soubory nebo složky, které nemají nekompatibilní názvy se systémem souborů jiné platformy. Ochrana úložiště před touto nekompatibilitou je důležitá, protože vývojáři na jiných platformách můžou neúmyslně rezervovat potvrzení, které poškodí jejich pracovní adresáře kvůli nepodporovaným názvům souborů nebo cest.

Azure Repos nabízí tři nastavení kompatibility mezi platformami, která pomáhají chránit vaše úložiště před lidmi, kteří odsílají potvrzení, která nejsou kompatibilní s jednou nebo více platformami. Tato nastavení souvisejí s následujícími omezeními systémů souborů:

  • Rozlišování malých a velkých písmen
  • Omezení názvů souborů a složek
  • Omezení délky cesty

Rozlišování malých a velkých písmen

Systémy souborů Windows a macOS nerozlišují velká a malá písmena (ale ve výchozím nastavení se zachovávají malá a velká písmena). U většiny linuxových systémů souborů se rozlišují malá a velká písmena. Git byl původně sestavený jako systém správy verzí jádra Linuxu, takže se rozlišují malá a velká písmena.

I když Git pro Windows řeší řadu problémů s operačním systémem bez rozlišování malých a malých písmen, zůstává několik dotazů.

Názvy souborů a složek

V Linuxu není problém rezervace úložiště Git, které obsahuje File.txt i file.txt . Jedná se o odlišné názvy souborů. V systému Windows a macOS rezervace obou souborů způsobí, že druhý soubor přepíše první. Pokud se dvě složky liší pouze v případě, že se jejich obsah spojí dohromady v systémech souborů bez rozlišování malých a malých písmen.

Úložiště, které má konflikty s případy, se dají vyřešit dvěma způsoby:

  • Podívejte se na úložiště v prostředí s rozlišováním malých a malých písmen. Přejmenujte soubory a složky tak, aby už nebyly v konfliktu, a pak tyto změny nasdílejte do úložiště. Subsystém Windows pro Linux je jedním z takových prostředí.
  • Pro každý konflikt použijte příkaz git mv -f <conflicting name> <non-conflicting name> . Dávejte pozor, abyste u obou názvů souborů použili přesné velká písmena.

Je dobré se vyhnout vzniku konfliktů případů na prvním místě. Azure Repos nabízí nastavení vynucení případu, které zabrání nabízení, které by k této situaci vedlo. Vývojářům pomůže také používání funkce dokončování tabulátoru k potvrzení souborů. Vzhledem k tomu, že windows i macOS se zachovávají velká a malá písmena, tyto přístupy zajišťují, že interní údaje Gitu vidí přesně stejné písmeno, které systém souborů používá.

Názvy větví a značek

Můžete vytvořit dvě větve nebo značky (označované jako odkazy), které se liší pouze v velikostech. Interní informace Gitu spolu s Azure DevOps Services a Azure DevOps Serverem považují za dvě samostatné odkazy. Git na počítači uživatele používá systém souborů k ukládání refs. Načtení a další operace začnou selhávat kvůli nejednoznačnosti.

Malý soubor představuje každý odkaz. Pokud název odkazu obsahuje znaky lomítka (/), představují složky části před posledním lomítkem.

Jedním z jednoduchých způsobů, jak se vyhnout problémům, je vždy používat názvy větví a značek malými písmeny. Pokud jste už vytvořili dvě větve nebo značky, které tento problém mají, můžete je opravit ve webovém uživatelském rozhraní Azure Repos.

Oprava názvů větví:

  1. Na stránce větví přejděte na související potvrzení.
  2. V místní nabídce vyberte Nová větev.
  3. Dejte větvi nový název, který nemá konflikt velkých a malých písmen.
  4. Vraťte se na stránku větví a odstraňte konfliktní větev.

Oprava názvů značek:

  1. Na stránce pro značky přejděte na označené potvrzení.
  2. V místní nabídce vyberte Vytvořit značku.
  3. Dejte značce nový název, který nemá konflikt písmen.
  4. Vraťte se na stránku pro značky a odstraňte konfliktní značku.

Omezení pro cestu a název souboru

Operační systémy Windows, macOS a Linux mají různá omezení pro názvy a cesty souborů. Tato omezení omezují, co můžete pojmenovat soubory nebo složky, což může způsobit problémy pro týmy, které používají Git na různých platformách.

Představte si například, že vývojář na jedné platformě potvrdí změnu do sdíleného úložiště, které obsahuje název souboru nebo délku cesty, která je neplatná na jiné platformě. Později se jiný vývojář pokusí toto potvrzení rezervovat na platformě, kde je obsah neplatný. Výsledkem této situace je poškozený pracovní adresář, který může poškodit úložiště poškozenými daty.

Azure Repos nabízí nastavení úložiště, která blokují nabízená oznámení obsahující potvrzení, která porušují jedno nebo více následujících omezení.

Referenční tabulka názvů souborů a cest

Omezení/platformy Windows macOS Linux
Omezení názvů souborů Rezervované názvy souborů: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9

Názvy rezervovaných souborů následované .

Rezervované znaky: \ / : * ? " < >

Názvy souborů, které končí nebo . prázdné znaky
Názvy souborů, které končí na / Názvy souborů, které končí na /
Omezení délky cesty Cesty ve Windows mají maximální délku 260 znaků (včetně ukončovací funkce null).

U adresářů s .NET musí mít plně kvalifikovaný název souboru méně než 260 znaků a název adresáře musí být menší než 248 znaků.
Názvy souborů jsou omezené na 255 znaků.

Maximální počet cest v HFS+ je zdokumentován jako neomezený, i když některé verze macOS mají maximální počet cest na 1 016znakůch Některé systémy souborů podporují maximální cestu 1 016.
Názvy souborů jsou omezené na 255 znaků.

Maximální cesta je 4096.

Podpora kódování

Poznámka:

Podpora kódování, kterou tato část popisuje, je podporována v Azure DevOps Serveru 2019.1 a novějším.

Společnost Microsoft přidala podporu kódování UTF-16 a UTF-32 prostřednictvím koncového bodu pro odesílání webových oznámení. Tato podpora znamená, že zachováváme typ kódování, takže soubory nemusíte přepisovat jako UTF-8. Zobrazí se také upozornění při pokusu o uložení souboru, který není kódován UTF přes web (který podporuje pouze kódování UTF).

Následující snímek obrazovky ukazuje příklad dialogového okna, které se zobrazí při zavádění změn kódování pomocí webové nabízené oznámení.

Snímek obrazovky s dialogovým oknem o představení změn kódování prostřednictvím webového nabízení