Git-plattformsoberoende kompatibilitet

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

Windows-, macOS- och Linux-filsystemen har begränsningar och beteenden som en eller flera av de andra plattformarna inte alltid stöder. Eftersom Git är en plattformsoberoende teknik är det möjligt för en utvecklare på en plattform att göra en incheckning som innehåller filer eller mappar som har inkompatibla namn med en annan plattforms filsystem. Det är viktigt att skydda lagringsplatsen från den här inkompatibiliteten eftersom utvecklare på andra plattformar omedvetet kan checka ut en incheckning som skadar deras arbetskataloger på grund av fil- eller sökvägsnamn som inte stöds.

Azure Repos erbjuder tre plattformsoberoende kompatibilitetsinställningar som skyddar din lagringsplats från personer som push-överför incheckningar som är inkompatibla med en eller flera plattformar. De här inställningarna gäller följande begränsningar för filsystem:

• Skiftlägeskänslig
• Begränsningar för fil- och mappnamn
• Begränsningar för sökvägslängd

Skiftlägeskänslig

Windows- och macOS-filsystemen är skiftlägesokänsliga (men skiftlägesbevarande) som standard. De flesta Linux-filsystem är skiftlägeskänsliga. Git skapades ursprungligen för att vara Linux-kernelns versionskontrollsystem, så det är skiftlägeskänsligt.

Även om Git för Windows löser många av problemen med ett skiftlägesokänsligt operativsystem återstår några egenheter.

Fil- och mappnamn

I Linux är det inga problem att checka ut en Git-lagringsplats som innehåller både File.txt och file.txt . Det är distinkta filnamn. Om du checkar ut båda filerna i Windows och macOS skrivs den andra över den första. Om två mappar endast skiljer sig åt från fall till fall blandas deras innehåll i skiftlägesokänsliga filsystem.

Det finns två sätt att åtgärda en lagringsplats som har skiftlägeskonflikter:

• Kolla in lagringsplatsen i en skiftlägeskänslig miljö. Byt namn på filer och mappar så att de inte längre är i konflikt och skicka sedan ändringarna till lagringsplatsen. Windows-undersystem för Linux är en sådan miljö.
• Använd kommandot git mv -f <conflicting name> <non-conflicting name> för varje konflikt. Var noga med att använda exakta versaler för båda filnamnen.

Det är bra att undvika att skapa fallkonflikter i första hand. Azure Repos erbjuder en inställning för tvingande av ärenden för att förhindra push-överföring som skulle leda till den här situationen. För utvecklare hjälper det också att använda flikens slutförande för att checka in filer. Eftersom både Windows och macOS är skiftlägesbevarande ser dessa metoder till att Gits interna enheter ser exakt samma hölje som filsystemet använder.

Gren- och taggnamn

Du kan skapa två grenar eller taggar (kallas refs) som endast skiljer sig åt i höljet. Gits interna enheter, tillsammans med Azure DevOps Services och Azure DevOps Server, behandlar dem som två separata refs. På en användares dator använder Git filsystemet för att lagra referenserna. Hämtningar och andra åtgärder börjar misslyckas på grund av tvetydigheten.

En liten fil representerar varje referens. Om ett referensnamn innehåller snedstreckstecken (/) representerar mappar delarna före det sista snedstrecket.

Ett enkelt sätt att undvika problem är att alltid använda gren- och taggnamn med gemener. Om du redan har skapat två grenar eller taggar som har det här problemet kan du åtgärda dem i webbgränssnittet för Azure Repos.

Så här åtgärdar du grennamn:

1. På sidan för grenar går du till den relaterade incheckningen.
2. På snabbmenyn väljer du Ny gren.
3. Ge grenen ett nytt namn som inte har en ärendekonflikt.
4. Gå tillbaka till sidan för grenar och ta bort den gren som är i konflikt.

Så här åtgärdar du taggnamn:

1. På sidan för taggar går du till den taggade incheckningen.
2. På snabbmenyn väljer du Skapa tagg.
3. Ge taggen ett nytt namn som inte har en ärendekonflikt.
4. Gå tillbaka till sidan för taggar och ta bort taggen som är i konflikt.

Sökvägs- och filnamnsbegränsningar

Operativsystemen Windows, macOS och Linux har olika begränsningar för filnamn och sökvägar. Dessa begränsningar begränsar vad du kan namnge filer eller mappar, vilket kan skapa problem för team som använder Git på flera plattformar.

Anta till exempel att en utvecklare på en plattform genomför en ändring av den delade lagringsplatsen som innehåller ett filnamn eller sökvägslängd som är ogiltigt på en annan plattform. Senare försöker en annan utvecklare checka ut incheckningen på en plattform där innehållet är ogiltigt. Den här situationen resulterar i en skadad arbetskatalog som kan skada lagringsplatsen med skadade data.

Azure Repos erbjuder lagringsplatsinställningar som blockerar push-meddelanden som innehåller incheckningar som bryter mot en eller flera av följande begränsningar.

Referenstabell för filnamn och sökvägar

Begränsningar/plattformar	Windows	macOS	Linux
Filnamnsbegränsningar	Reserverade filnamn: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Reserverade filnamn följt av . Reserverade tecken: \ / : * ? " < > Filnamn som slutar i . eller tomt utrymme	Filnamn som slutar i /	Filnamn som slutar i /
Begränsningar för sökvägslängd	Sökvägar i Windows har en maximal längd på 260 tecken (inklusive en null-avslut). För kataloger med .NET måste det fullständigt kvalificerade filnamnet vara färre än 260 tecken och katalognamnet måste vara färre än 248 tecken.	Filnamn är begränsade till 255 tecken. Sökvägsmaxieringar i HFS+ dokumenteras som obegränsade, även om vissa macOS-versioner har ett tak på 1 016 tecken. Vissa filsystem stöder 1 016 som maximal sökväg.	Filnamn är begränsade till 255 tecken. Maximal sökväg är 4 096.

Kodningsstöd

Microsoft har lagt till stöd för UTF-16- och UTF-32-kodning via webb-push-slutpunkten. Det här stödet innebär att vi bevarar kodningstypen, så att du inte behöver skriva om filerna som UTF-8. Du ser också en varning när du försöker spara en fil som inte är UTF-kodad via webben (som endast stöder UTF-kodning).

Följande skärmbild visar ett exempel på den dialogruta som visas när du introducerar kodningsändringar med hjälp av en webb-push.