Compatibilité multiplateforme Git

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

Les systèmes de fichiers Windows, macOS et Linux ont des limitations et des comportements que l’une ou plusieurs des autres plateformes ne prennent pas toujours en charge. Étant donné que Git est une technologie multiplateforme, il est possible pour un développeur sur une plateforme de valider qui contient des fichiers ou des dossiers qui ont des noms incompatibles avec le système de fichiers d’une autre plateforme. La protection de votre dépôt contre cette incompatibilité est importante, car les développeurs sur d’autres plateformes peuvent sans le savoir vérifier une validation qui endommage leurs répertoires de travail en raison 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 dépôt contre les validations push de personnes incompatibles avec une ou plusieurs plateformes. Ces paramètres sont liés aux limitations suivantes avec les systèmes de fichiers :

• Respect de la casse
• Restrictions sur les noms de fichiers et de dossiers
• Restrictions de longueur du chemin d’accès

Respect de la casse

Les systèmes de fichiers Windows et macOS ne respectent pas la casse (mais conservent la casse) par défaut. La plupart des systèmes de fichiers Linux respectent la casse. Git a été créé à l’origine pour être le système de contrôle de version du noyau Linux. Il est donc sensible à la casse.

Bien que Git pour Windows traite un grand nombre des problèmes liés à un système d’exploitation ne respectant pas la casse, quelques bizarres restent.

Noms de fichiers et de dossiers

Sur Linux, l’extraction d’un référentiel Git qui contient à la fois File.txt et file.txt n’est pas un problème. Il s’agit de noms de fichiers distincts. Sur Windows et macOS, l’extraction des deux fichiers entraîne le remplacement de la deuxième. Si deux dossiers diffèrent uniquement par cas, leur contenu est mélangé dans des systèmes de fichiers ne respectant pas la casse.

Il existe deux façons de corriger un référentiel qui a des conflits de cas :

• Consultez le référentiel dans un environnement respectant la casse. Renommez les fichiers et dossiers afin qu’ils ne soient plus en conflit, puis envoyez ces modifications au référentiel. Le sous-système Windows pour Linux est un environnement de ce type.
• Utilisez la commande git mv -f <conflicting name> <non-conflicting name> pour chaque conflit. Veillez à utiliser une mise en majuscule exacte sur les deux noms de fichiers.

Il est bon d’éviter de créer des conflits de cas en premier lieu. Azure Repos offre un paramètre d’application de la casse pour empêcher les envois (push) susceptibles d’entraîner cette situation. Pour les développeurs, l’adoption de l’habitude d’utiliser la saisie semi-automatique de tabulation pour valider des fichiers vous aidera également. Étant donné que Windows et macOS conservent des cas, ces approches garantissent que les 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 refs) qui diffèrent uniquement dans la casse. Les internes de Git, ainsi qu’Azure DevOps Services et Azure DevOps Server, les traitent comme deux références distinctes. Sur l’ordinateur d’un utilisateur, Git utilise le système de fichiers pour stocker les références. Les extractions et d’autres opérations commencent à échouer en raison de l’ambiguïté.

Un petit fichier représente chaque référence. Si un nom ref contient des caractères de barre oblique (/), les dossiers représentent les parties avant la barre oblique finale.

Une façon simple d’éviter les problèmes consiste à toujours utiliser des noms de branche et de balise 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 les noms de branche :

1. Sur 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 n’a pas de conflit de cas.
4. Revenez à la page des branches et supprimez la branche en conflit.

Pour corriger les noms des balises :

1. Sur 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 n’a pas de conflit de cas.
4. Revenez à la page des balises et supprimez la balise en conflit.

Restrictions de chemin d’accès et de nom de fichier

Les systèmes d’exploitation Windows, macOS et Linux ont diverses limitations pour les noms de fichiers et les chemins d’accès. Ces limitations limitent ce que vous pouvez nommer des fichiers ou des dossiers, ce qui peut créer des problèmes pour les équipes qui utilisent Git sur plusieurs plateformes.

Par exemple, imaginez qu’un développeur sur une plateforme valide une modification dans le référentiel partagé qui contient un nom de fichier ou une longueur de chemin d’accès non valide sur une autre plateforme. Plus tard, un autre développeur tente de vérifier cette validation sur une plateforme où le contenu n’est pas valide. Cette situation entraîne un répertoire de travail endommagé qui peut endommager votre dépôt avec des données endommagées.

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