Compatibilité multi-plateforme de Git

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

Les systèmes de fichiers Windows, macOS et Linux présentent des limitations et des comportements qu’une ou plusieurs autres plates-formes ne prennent pas toujours en charge. Git étant une technologie multi-plateforme, il peut arriver qu'un développeur travaillant sur une plate-forme fasse une validation contenant des fichiers ou des dossiers dont les noms sont incompatibles avec le système de fichiers d'une autre plate-forme. Il est important de protéger votre référentiel contre cette incompatibilité, car les développeurs d’autres plates-formes peuvent extraire sans le savoir une validation qui corrompt leurs dossiers de travail à cause de noms de fichiers ou de chemins non pris en charge.

Azure Repos offre trois paramètres de compatibilité multiplateforme qui aident à protéger votre référentiel contre les validations d’envoi de personnes incompatibles avec une ou plusieurs plateformes. Ces paramètres sont liés aux limitations suivantes concernant les systèmes de fichiers :

• Respect de la casse
• Restrictions relatives aux noms de fichiers et de dossiers
• Restrictions relatives à la longueur des chemins d'accès

Respect de la casse

Par défaut, les systèmes de fichiers de Windows et macOS les noms de dossiers sont insensibles à la casse (mais ils la respectent). La plupart des systèmes de fichiers Linux sont sensibles à la casse. Git ayant à l'origine été conçu pour être le système de gestion de version du noyau de Linux, il est sensible à la casse.

Bien que Git pour Windows résolve un grand nombre des problèmes liés à un système d’exploitation insensible à la casse, quelques anomalies subsistent.

Noms de fichiers et de dossiers

Sous Linux, l’extraction d’un référentiel Git contenant à la fois Fichier.txt et fichier.txt ne pose aucun problème. Ce sont des noms de fichiers distincts. En revanche, sous Windows et macOS, l’extraction de ces deux fichiers entraîne l’écrasement du premier par le second. Si les noms de deux dossiers ne diffèrent que par la casse, dans des systèmes de fichiers insensibles à la casse, leurs contenus se mélangent.

Il y a deux façons de corriger un référentiel qui présente des conflits de casse :

• Extraire le référentiel dans un environnement sensible à la casse. Renommer les fichiers et les dossiers afin qu’ils ne soient plus en conflit, puis transférer ces modifications dans le référentiel. Le sous-système Windows pour Linux est un environnement de ce type.
• Utiliser la commande git mv -f <conflicting name> <non-conflicting name> pour chaque conflit. Il faut veiller à utiliser la bonne casse sur les deux noms de fichiers.

Il est préférable d’éviter de créer des conflits de casse dès le départ. Azure Repos offre un réglage d’application de la casse pour empêcher les envois qui pourraient conduire à une telle situation. Pour les développeurs, il est également utile de prendre l’habitude d’utiliser la saisie semi-automatique via la touche tab pour valider les fichiers. Étant donné que Windows et macOS respectent la casse, ces approches garantissent que les éléments internes de Git voient exactement la même casse que celle utilisée par le système de fichiers.

Noms de branche et de balise

Vous pouvez créer deux branches ou balises (appelées réfs) ne différant que par leur casse. Les éléments internes de Git, ainsi qu’Azure DevOps Services et Azure DevOps Server, les considèrent comme deux réfs différentes. Sur l’ordinateur d’un utilisateur, Git utilise le système de fichiers pour stocker les réfs. Les extractions et d’autres opérations commencent à échouer en raison de l’ambiguïté.

Chaque réf est représentée par un petit fichier. Si le nom d'une réf contient des barres obliques (/), cela signifie que la partie située avant la dernière barre oblique correspond à un nom de dossier.

Un moyen simple d’éviter les problèmes est de toujours mettre les noms de branches et de balises en minuscules. Si vous avez déjà créé deux branches ou balises qui présentent ce problème, vous pouvez les corriger dans l’interface utilisateur web Azure Repos.

Pour corriger des noms de branches :

1. Dans la page des branches, accédez à la validation associée.
2. Dans le menu contextuel, sélectionnez Nouvelle branche.
3. Donnez à la branche un nouveau nom qui ne présente aucun conflit de casse.
4. Revenez à la page des branches et supprimez la branche qui est en conflit.

Pour corriger des noms de balises :

1. Dans la page des balises, accédez à la validation étiquetée.
2. Dans le menu contextuel, sélectionnez Créer une balise.
3. Donnez à la balise un nouveau nom qui ne présente aucun conflit de casse.
4. Revenez à la page des balises et supprimez la balise qui est en conflit.

Restrictions relatives au chemin d'accès et au nom de fichier

Les systèmes d’exploitation Windows, macOS et Linux imposent différentes limitations aux noms de fichiers et aux chemins d’accès. Ces limitations restreignent les noms que vous pouvez donner aux fichiers et aux dossiers, ce qui peut poser des problèmes aux équipes qui utilisent Git sur plusieurs plates-formes.

Imaginons par exemple que sur une plate-forme, un développeur valide une modification dans le référentiel partagé qui contient un nom de fichier ou une longueur de chemin d’accès non supportés par une autre plate-forme. Plus tard, un autre développeur tente d’extraire cette validation sur une plate-forme où les contenus ne sont pas valides. Cela donne lieu à un dossier de travail corrompu qui peut potentiellement endommager votre référentiel avec des données corrompues.

Azure Repos propose des ajustements du référentiel qui bloquent les envois contenant des validations qui enfreignent une ou plusieurs des limitations suivantes.

Tableau de référence pour les noms de fichiers et les chemins d’accès

Restrictions/Plates-formes	Windows	macOS	Linux
Restrictions concernant les noms de fichiers	Noms de fichiers réservés : CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 Noms de fichiers réservés suivis de . Caractères réservés : \ / : * ? " < > Noms de fichiers se terminant par . ou un espace	Noms de fichiers se terminant par /	Noms de fichiers se terminant par /
Restrictions relatives à la longueur des chemins d'accès	Dans Windows, les chemins d'accès ont une longueur maximale de 260 caractères (y compris un caractère nul). Pour les dossiers avec .NET, le nom de fichier complet doit comporter moins de 260 caractères et le nom du dossier doit être inférieur à 248 caractères.	Les noms de fichiers sont limités à 255 caractères. Dans HFS+, les chemins d'accès sont documentés comme étant illimités, mais certaines versions de macOS les restreignent à 1 016 caractères. Certains systèmes de fichiers supportent un chemin d'accès de 1 016 caractères maximum.	Les noms de fichiers sont limités à 255 caractères. Le chemin d'accès est de 4 096 caractères maximum.

Prise en charge du codage

Microsoft a ajouté la prise en charge de l’encodage UTF-16 et UTF-32 via le point de terminaison push web. Cette prise en charge signifie que le type d’encodage est conservé, de sorte que vous n’avez pas à réécrire vos fichiers en UTF-8. Un avertissement s’affiche également lorsque vous essayez d’enregistrer un fichier qui n’est pas encodé en UTF via le web (qui ne prend en charge que l’encodage UTF).

La capture d’écran suivante montre un exemple de la boîte de dialogue qui s’affiche lorsque vous introduisez des modifications d’encodage avec un push web.