Compatibiliteit tussen platforms in Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

De Windows-, macOS- en Linux-bestandssystemen hebben beperkingen en gedrag die een of meer van de andere platforms niet altijd ondersteunen. Omdat Git een platformoverschrijdende technologie is, is het mogelijk dat een ontwikkelaar op het ene platform een doorvoering maakt die bestanden of mappen bevat die incompatibele namen hebben met het bestandssysteem van een ander platform. Het beveiligen van uw opslagplaats tegen deze incompatibiliteit is belangrijk omdat ontwikkelaars op andere platforms onbedoeld een doorvoering kunnen uitchecken die hun werkmappen beschadigd vanwege niet-ondersteunde bestands- of padnamen.

Azure-opslagplaatsen bieden drie platformoverschrijdende compatibiliteitsinstellingen waarmee u uw opslagplaats kunt beschermen tegen personen die doorvoeringen pushen die niet compatibel zijn met een of meer platforms. Deze instellingen zijn gerelateerd aan de volgende beperkingen met bestandssystemen:

• Hoofdlettergevoelig
• Beperkingen voor bestands- en mapnamen
• Beperkingen voor padlengte

Hoofdlettergevoelig

De Windows- en macOS-bestandssystemen zijn standaard niet hoofdlettergevoelig (maar hoofdletterbehoud). De meeste Linux-bestandssystemen zijn hoofdlettergevoelig. Git is oorspronkelijk gebouwd als het versiebeheersysteem van de Linux-kernel, dus het is hoofdlettergevoelig.

Hoewel Git voor Windows veel van de problemen met een niet-hoofdlettergevoelig besturingssysteem verhelpt, blijven er enkele zaken bestaan.

Bestands- en mapnamen

In Linux is het uitchecken van een Git-opslagplaats met zowel File.txt alsfile.txt geen probleem. Dit zijn afzonderlijke bestandsnamen. In Windows en macOS zorgt het uitchecken van beide bestanden ervoor dat de tweede de eerste overschrijft. Als twee mappen alleen per geval verschillen, worden de inhoud ervan gecombineerd in hoofdlettergevoelige bestandssystemen.

Er zijn twee manieren om een opslagplaats met caseconflicten op te lossen:

• Bekijk de opslagplaats in een hoofdlettergevoelige omgeving. Wijzig de naam van bestanden en mappen zodat ze niet meer conflicteren en push deze wijzigingen vervolgens naar de opslagplaats. Windows-subsysteem voor Linux is een dergelijke omgeving.
• Gebruik de opdracht git mv -f <conflicting name> <non-conflicting name> voor elk conflict. Wees voorzichtig met exact hoofdlettergebruik voor beide bestandsnamen.

Het is goed om te voorkomen dat er in de eerste plaats sprake is van conflicten tussen hoofdletters en kleine letters. Azure-opslagplaatsen bieden een instelling voor het afdwingen van cases om pushes te voorkomen die tot deze situatie zouden leiden. Ontwikkelaars helpen ook bij het gebruik van de gewoonte om tabvoltooiing te gebruiken om bestanden door te voeren. Omdat zowel Windows als macOS hoofdletters behouden zijn, zorgen deze benaderingen ervoor dat de interne functies van Git precies dezelfde behuizing zien die door het bestandssysteem wordt gebruikt.

Namen van vertakkingen en tags

U kunt twee vertakkingen of tags (ook wel refs genoemd ) maken die alleen in hoofdletters verschillen. De interne functies van Git, samen met Azure DevOps Services en Azure DevOps Server, behandelen ze als twee afzonderlijke refs. Op de computer van een gebruiker gebruikt Git het bestandssysteem om refs op te slaan. Ophalen en andere bewerkingen mislukken vanwege de dubbelzinnigheid.

Een klein bestand vertegenwoordigt elke ref. Als een verw-naam slash(/) tekens bevat, vertegenwoordigen mappen de onderdelen vóór de laatste slash.

Een eenvoudige manier om problemen te voorkomen, is door altijd alle kleine letters en tagnamen te gebruiken. Als u al twee vertakkingen of tags met dit probleem hebt gemaakt, kunt u deze oplossen in de webgebruikersinterface van Azure-opslagplaatsen.

Vertakkingsnamen herstellen:

1. Ga op de pagina voor vertakkingen naar de gerelateerde doorvoering.
2. Selecteer Nieuwe vertakking in het snelmenu.
3. Geef de vertakking een nieuwe naam die geen caseconflict heeft.
4. Ga terug naar de pagina voor vertakkingen en verwijder de conflicterende vertakking.

Tagnamen herstellen:

1. Ga op de pagina voor tags naar de getagde doorvoer.
2. Selecteer Tag maken in het snelmenu.
3. Geef de tag een nieuwe naam die geen caseconflict heeft.
4. Ga terug naar de pagina voor tags en verwijder de conflicterende tag.

Beperkingen voor pad- en bestandsnaam

De Windows-, macOS- en Linux-besturingssystemen hebben verschillende beperkingen voor bestandsnamen en paden. Deze beperkingen beperken wat u bestanden of mappen kunt noemen, waardoor problemen kunnen ontstaan voor teams die Git op meerdere platforms gebruiken.

Stel dat een ontwikkelaar op het ene platform een wijziging doorvoert in de gedeelde opslagplaats die een bestandsnaam of padlengte bevat die ongeldig is op een ander platform. Later probeert een andere ontwikkelaar die doorvoer uit te checken op een platform waar de inhoud ongeldig is. Deze situatie resulteert in een beschadigde werkmap die het potentieel heeft om uw opslagplaats te beschadigen met beschadigde gegevens.

Azure-opslagplaatsen bieden opslagplaatsinstellingen die pushes blokkeren die doorvoeringen blokkeren die een of meer van de volgende beperkingen schenden.

Referentietabel voor bestandsnamen en paden

Beperkingen/platforms	Windows	macOS	Linux
Beperkingen voor bestandsnaam	Gereserveerde bestandsnamen: CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Gereserveerde bestandsnamen gevolgd door . Gereserveerde tekens: \ / : * ? " < > Bestandsnamen die eindigen op . of witruimte	Bestandsnamen die eindigen op /	Bestandsnamen die eindigen op /
Beperkingen voor padlengte	Paden in Windows hebben een maximale lengte van 260 tekens (inclusief een null-eindteken). Voor mappen met .NET moet de volledig gekwalificeerde bestandsnaam minder dan 260 tekens lang zijn en moet de mapnaam uit minder dan 248 tekens bestaan.	Bestandsnamen zijn beperkt tot 255 tekens. Padlimieten in HFS+ worden gedocumenteerd als onbeperkt, hoewel sommige macOS-versies cap-paden met 1016 tekens bevatten. Sommige bestandssystemen ondersteunen 1016 als het maximale pad.	Bestandsnamen zijn beperkt tot 255 tekens. Het pad is maximaal 4096.

Ondersteuning voor codering

Microsoft heeft ondersteuning toegevoegd voor UTF-16- en UTF-32-codering via het webpusheindpunt. Deze ondersteuning betekent dat we het coderingstype behouden, zodat u uw bestanden niet opnieuw hoeft te schrijven als UTF-8. U ziet ook een waarschuwing wanneer u probeert een bestand op te slaan dat niet UTF is gecodeerd via internet (die alleen UTF-codering ondersteunt).

In de volgende schermopname ziet u een voorbeeld van het dialoogvenster dat wordt weergegeven wanneer u coderingswijzigingen introduceert met behulp van een webpush.