git core.autocrlf : maîtriser CRLF et LF entre Windows, macOS et Linux

Qu'est-ce que core.autocrlf ?

C'est un réglage Git qui convertit les fins de ligne entre votre système (CRLF sous Windows, LF ailleurs) et le dépôt.

Les éléments clés à connaître pour maîtriser core.autocrlf :

1 Valeurs de core.autocrlf et effets

Détermine comment Git convertit EOL à l'entrée/sortie.

true - Checkout: LF→CRLF | Commit: CRLF→LF
input - Checkout: inchangé | Commit: CRLF→LF
false - Aucune conversion

2 Fins de ligne selon les plateformes

Comprendre les codes pour éviter les confusions.

LF (10) - Unix/macOS
CRLF (13,10) - Windows
CR (13) - Ancien macOS (legacy)

3 .gitattributes et normalisation des EOL

Précisez la politique de fin de ligne au niveau du repo :

* text=auto

* text eol=lf

*.sh text eol=lf

*.bat text eol=crlf

4 Mécanismes Git associés

Options utiles pour sécuriser vos conversions :

core.safecrlf=true

git ls-files --eol

git add --renormalize .

.gitattributes: -text pour binaires

Problèmes classiques

Clonage et diff massif sans vrai changement

Un mauvais réglage provoque la conversion de milliers de lignes (LF↔CRLF).

Scripts et containers cassés par ^M

Un fichier .sh en CRLF déclenche “/bin/sh^M: bad interpreter”.

Boucles de formatage à chaque commit

Prettier/Linters réécrivent les fins de ligne en continu, l’historique devient bruyant.

CI verte en local, rouge sur le serveur

Des tests passent sous Windows mais échouent en Linux à cause des EOL.

Exemple de problème courant :

# Fichier committé en LF, checkout sur Windows avec conversions

git config core.autocrlf true

git ls-files --eol README.md # wcrlf attr/text eol=lf

git diff -- README.md # ❌ Diff CRLF↔LF sans modification de contenu

Symptômes qui doivent vous alerter

🚨 Signaux d'alarme

!

Un diff Git montre des milliers de lignes modifiées alors que rien n’a changé

!

Des scripts affichent “^M” ou “bad interpreter” sur Linux/macOS

!

Des snapshots/tests échouent avec des différences de fin de ligne

!

Docker/CI refuse d’exécuter des fichiers copiés avec CRLF

!

Des fichiers apparaissent modifiés immédiatement après un clone

Comment les détecter

✨ Solution recommandée : .gitattributes + core.autocrlf

Définissez les fins de ligne une fois pour toutes avec .gitattributes et ajustez core.autocrlf selon votre équipe. Git appliquera les conversions de manière cohérente, quel que soit l’OS.

✅ Normalisation contrôlée

text=auto, eol=lf/crlf, fichiers binaires protégés

📊 Inspection facile

git ls-files --eol pour voir l’état réel des EOL

🧹 Renormalisation

git add --renormalize . pour aligner tout l’historique

💾 Cohérence d’équipe

Même rendu de fichiers sur Windows, macOS et Linux

🔧 Configurer core.autocrlf et .gitattributes

Autres méthodes de détection

Affichage dans l'éditeur

✓ Activez l’affichage des EOL et du symbole CRLF/LF (VS Code, JetBrains, Sublime)

✓ Utilisez EditorConfig pour forcer end_of_line=lf ou crlf par type de fichier

En ligne de commande (Unix)

# Inspecter les fins de ligne suivies par Git

git ls-files --eol

# Renormaliser selon .gitattributes

git add --renormalize .

# Afficher les caractères ^M (CR)

sed -n l fichier.txt

# Voir les octets et vérifier 0d 0a

hexdump -C fichier.txt

En code

JavaScript

const normalized = str.replace(/\r\n/g, '\n');

Python

sum(1 for line in open("f.txt", "rb") if b"\r\n" in line)

Excel / Google Sheets

CODE(MID(cellule;position;1))=13 /* CR */

Nettoyer et prévenir

🚀 Solution rapide avec .gitattributes

Avant toute manipulation manuelle, posez un .gitattributes clair et renormalisez le dépôt pour repartir proprement.

✓ * text=auto et eol=lf/crlf selon besoin

✓ git add --renormalize . puis commit

✓ Activez core.safecrlf pour éviter les erreurs

Mettre en place maintenant

Méthodes techniques avancées

🔧 Normaliser

✓ Privilégiez eol=lf dans .gitattributes pour le code source

✓ Utilisez core.autocrlf=input pour projets multi-OS (souvent recommandé)

✓ Convertissez l’existant (dos2unix/unix2dos) avant de committer

🧹 Filtrer

✓ Marquez les binaires avec -text pour éviter toute conversion

✓ Forcez eol=lf pour scripts, YAML, Dockerfile, JSON

✓ Activez core.safecrlf=true pour bloquer des mélanges CRLF/LF

⚙️ Automatiser

✓ Hooks pre-commit pour refuser des fichiers en CRLF non désirés

✓ CI: exécutez git ls-files --eol et échouez sur anomalies

✓ Partagez un .editorconfig avec end_of_line uniforme

Checklist rapide

.gitattributes versionné avec text=auto et eol défini

core.autocrlf paramétré (input, true ou false) et documenté

core.safecrlf activé pour prévenir les mélanges

Renormalisation effectuée et commit d’alignement réalisé

.editorconfig partagé avec end_of_line cohérent

Vérifications CI pour repérer et refuser CRLF indésirables

Conclusion

Les retours de ligne ne devraient jamais polluer vos commits. En cadrant core.autocrlf et .gitattributes, vous supprimez une grande source de bruit et d'erreurs.

Fixez des règles simples, renormalisez une fois, automatisez les contrôles et vos équipes collaborent sans friction entre OS.

git core.autocrlf : CRLF vs LF sans mauvaises surprises