Pour que Git enregistre une modification de nom de fichier qui ne change que la casse — comme readme.md en README.md —, exécutez git mv depuis le dépôt dans le Terminal, puis vérifiez la modification indexée avec git status. Sur de nombreux Mac, le format APFS par défaut préserve la casse des noms de fichiers mais ne les distingue pas selon la casse, de sorte qu’un renommage dans le Finder ou un simple mv peut empêcher Git de détecter la différence. Apple précise qu'APFS peut également être formaté en respectant la casse, le comportement dépend donc du volume. Apple Developer: Files and directories

Renommer un fichier suivi avec git mv

Dans le Terminal, déplacez-vous dans le dépôt qui contient le fichier. Remplacez les chemins d'exemple ci-dessous par les chemins actuels et souhaités exacts. Mettre chaque chemin entre guillemets est une bonne pratique si un nom contient des espaces ou des métacaractères du shell.

git mv 'src/readme.md' 'src/README.md'
git status

La commande git mv de Git renomme le chemin dans la copie de travail (working tree) et met à jour l'index ; la modification est indexée (staged), mais elle doit encore être commitée. Le manuel de Git exige que le chemin source existe et indique que la mise à jour de l'index s'effectue après un déplacement réussi. Le flux de travail documenté en ligne de commande par GitHub recommande également de vérifier git status après git mv. Documentation de git-mv GitHub Docs: Renaming a file

En cas de succès, examinez la sortie de la commande de statut pour repérer un renommage indexé de l'ancien chemin vers le nouveau. Vérifiez l'ensemble des modifications indexées avant de commiter, surtout si vous avez également modifié le fichier :

git diff --cached --summary
git diff --cached -- 'src/README.md'

Le résumé permet de confirmer le changement de chemin ; la seconde commande vous permet d'inspecter le contenu indexé pour ce chemin. Git peut afficher un renommage sous la forme d'une suppression et d'un ajout dans certains contextes, car la présentation des renommages est déduite du contenu des fichiers et de l'historique. La vérification essentielle ici est de s'assurer que l'index contient bien le chemin souhaité et aucune modification indexée involontaire.

Si un renommage direct ne modifiant que la casse échoue

Certains volumes insensibles à la casse ou certaines configurations de Git n'acceptent pas un déplacement direct dont la source et la destination ne diffèrent que par la casse. Utilisez un nom temporaire avec une orthographe différente, puis déplacez ce chemin temporaire vers le nom final :

git mv 'src/readme.md' 'src/readme-case-tmp.md'
git mv 'src/readme-case-tmp.md' 'src/README.md'
git status

Le chemin temporaire ne doit pas déjà exister. Après avoir exécuté les deux commandes, confirmez que le statut n'affiche que le renommage attendu de l'ancien vers le nouveau nom, et vérifiez le diff indexé. Cette méthode en deux étapes offre au système de fichiers un nom intermédiaire pour faire la distinction, tandis que git mv met à jour l'index de Git à chaque étape réussie. Si l'une des commandes renvoie une erreur, arrêtez-vous et examinez git status ainsi que le répertoire avant de réessayer ; n'ajoutez pas -f à moins d'avoir confirmé qu'écraser la destination est bien intentionnel.

Vérifier la gestion de la casse du dépôt

Le paramètre core.ignoreCase de Git active des solutions de contournement pour les systèmes de fichiers qui ne distinguent pas la casse des lettres. La documentation de Git indique que clone et init sondent le système de fichiers et définissent cette valeur de manière appropriée ; elle avertit également que la modifier peut entraîner des comportements inattendus. Vous pouvez inspecter le paramètre effectif avec : Documentation de git-config

git config --get core.ignoreCase

Si aucune valeur n'est affichée, cette commande n'a pas trouvé de paramètre dans la configuration effective. Évitez de considérer git config core.ignoreCase false comme la solution : cela modifie les présomptions de Git, mais ne permet pas à un volume macOS insensible à la casse de stocker dans un même répertoire deux noms qui ne diffèrent que par la casse. L'objectif documenté de ce paramètre est d'aider Git à fonctionner avec le comportement réel du système de fichiers, et non de modifier ce comportement.

Confirmer, commiter et partager le renommage

Avant de commiter, vérifiez l'orthographe finale dans git status, examinez le résumé indexé et vérifiez qu'aucune modification non liée n'est incluse. Lorsque le renommage indexé est correct, commitez-le avec un message clair :

git commit -m "Rename readme file to uppercase"

Si vous prévoyez de partager le commit, poussez la branche en utilisant le workflow habituel de dépôt distant et de branche de votre projet. Le renommage est enregistré dans le commit ; un dépôt distant ne le recevra qu'une fois que vous aurez poussé. Sur un volume APFS sensible à la casse, des noms ne différant que par la casse peuvent être distincts, tandis que la configuration par défaut insensible à la casse les traite comme le même nom. La vérification locale la plus fiable consiste toujours à s'assurer que l'index de Git et l'état des modifications indexées affichent le chemin de destination souhaité. Apple Support: File system formats available in Disk Utility on Mac

Sources