Dans une équipe où une partie des développeurs travaille sous Windows et l'autre sous macOS ou sur des serveurs GitLab CI en Linux, le choix du réglage core.autocrlf n'est pas un détail de configuration personnelle : mal réglé, il transforme des commits qui ne touchent qu'une ligne en diffs de fichier entier, illisibles en revue de code.
D'où vient cette divergence
Unix et macOS utilisent un seul caractère : LF (line feed, \n). Windows a hérité des vieux téléscripteurs une paire de caractères : CRLF (carriage return + line feed, \r\n) — l'un ramène le chariot au début de la ligne, l'autre descend d'une ligne, une imitation littérale d'une machine à écrire.
Pourquoi ça compte encore
- Git. Si un fichier en CRLF atterrit dans un dépôt où les autres fichiers sont en LF, git peut afficher « fichier entièrement modifié » alors qu'une seule ligne a été éditée — car techniquement les fins de toutes les lignes ont changé.
- Scripts avec shebang. Un script shell Unix enregistré avec des fins CRLF peut ne pas s'exécuter sur un serveur de déploiement, car l'interpréteur voit un caractère
\rsuperflu sur la première ligne. - Comparaison de chaînes dans le code. Une ligne lue depuis un fichier CRLF peut ne pas correspondre à une chaîne LF attendue, même si le texte visible paraît identique.
Comment on gère ça
Git dispose d'un réglage (core.autocrlf) qui convertit automatiquement les fins de ligne lors du checkout/commit, mais s'appuyer sur la configuration locale de chaque personne reste fragile. Fixer le style dans un fichier .gitattributes versionné avec le dépôt est plus fiable : la règle s'applique alors à tout le monde, quel que soit l'éditeur ou le système utilisé.
À quoi sert la conversion manuelle
- Corriger un fichier arrivé dans le dépôt avec le mauvais style de fin de ligne.
- Préparer un script pour un serveur de déploiement Linux qui a été édité dans un éditeur Windows.
- Diagnostiquer pourquoi une comparaison textuelle de deux fichiers apparemment identiques révèle une différence.
Fins de ligne mixtes dans un même fichier
Un fichier édité dans plusieurs éditeurs ou sur différents systèmes d'exploitation peut contenir à la fois du CRLF et du LF — une partie des lignes dans un style, une partie dans l'autre. C'est le cas le plus délicat : convertir « en LF » ne change en apparence rien pour les lignes déjà en LF, mais il est important d'appliquer la conversion à tout le fichier, pas seulement aux lignes visiblement « suspectes », sinon le problème reste caché.