Respect de la casse Git

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

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, donc sans surprise, il respecte la casse.

Bien que la plupart des problèmes liés à un système d’exploitation ne respectant pas la casse aient été résolus dans Git pour Windows, quelques particularités subsistent.

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 l’écrasement du premier. Si deux dossiers diffèrent uniquement par la casse, leur contenu se retrouve mélangé sur des systèmes de fichiers ne respectant pas la casse.

Résolution des conflits de cas

Une façon de résoudre un référentiel avec ce problème consiste à l’extraire dans un environnement sensible à 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. Une autre approche consiste à utiliser la commande git mv -f <conflicting name> <non-conflicting name> pour chaque conflit, en faisant attention à utiliser une mise en majuscule exacte sur les deux noms de fichiers.

Éviter les conflits de cas

Il est bon d’éviter de créer cette situation en premier lieu. Azure Repos offre un paramètre d’application de la casse pour empêcher les envois qui entraînent 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 la casse, cela garantit 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/TFS, les traitent comme deux références distinctes. Sur la machine 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é. Chaque référence est représentée par un petit fichier et, si un nom de référence contient des caractères /, les parties avant le / final sont représentées par des dossiers.

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 avec ce problème, vous pouvez le résoudre dans l’interface utilisateur web Azure Repos.

Correction des noms de branche

Dans la page branches, accédez à la validation associée. Dans le menu contextuel, choisissez « Nouvelle branche ». Donnez à la branche un nouveau nom qui n’a pas de conflit de cas. Revenez à la page Branches et supprimez la branche en conflit.

Correction des noms d’étiquettes

Les étapes de résolution d’un nom de balise sont similaires aux branches. Dans la page Balises, accédez à la validation marquée. Dans le menu contextuel, choisissez « Créer une balise ». Donnez à la balise un nouveau nom qui n’a pas de conflit de cas. Revenez à la page Balises et supprimez la balise en conflit.