Si Git marque soudainement presque tous les fichiers comme modifiés sur votre Mac, la conversion des fins de ligne peut faire différer la copie de travail de la version suivie par Git. Inspectez d'abord le dépôt avant de modifier ou de restaurer des fichiers. Utilisez ensuite des paramètres Git adaptés à macOS, et ne renormalisez qu'après avoir protégé les véritables modifications. Git recommande de stocker le texte avec des fins de ligne LF ; ses recommandations pour macOS préconisent core.autocrlf input. Guide de GitHub sur les fins de ligne

Pourquoi les fins de ligne peuvent-elles faire apparaître chaque fichier comme modifié ?

Une fin de ligne marque la fin de chaque ligne : le format LF de type Unix utilise un seul caractère, tandis que le format CRLF de type Windows utilise un retour chariot suivi d'un saut de ligne. Si Git ou un éditeur modifie les fins de ligne dans l'ensemble d'une copie de travail, Git peut signaler des modifications de fichiers étendues, même si le texte lui-même semble identique. Git peut normaliser le texte en LF dans son index et appliquer différentes fins de ligne lors de l'extraction des fichiers, selon la configuration et le fichier .gitattributes. Documentation de Git sur gitattributes

Inspecter le dépôt avant de corriger le problème

Ouvrez le Terminal, accédez au dépôt et vérifiez son statut ainsi que ses paramètres de fin de ligne :

git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol

La commande de configuration peut ne rien afficher si aucune valeur n'est définie. --show-origin permet d'identifier quel fichier de configuration a fourni le paramètre. Dans git ls-files --eol, comparez les fins de ligne de l'index (i/) et de l'arbre de travail (w/) ; la mention mixed indique des fins de ligne mixtes. La valeur attr/ affiche les attributs applicables. Git documente cette sortie comme un diagnostic de l'index, de l'arbre de travail et des attributs de fin de ligne. Documentation de Git sur git-ls-files

Vérifiez également la présence de modifications réelles avant de continuer. Si vous trouvez des modifications que vous souhaitez conserver, validez-les (commit) ou copiez-les dans un endroit sûr. N'utilisez pas de restauration globale ou de réinitialisation (reset) comme solution aux problèmes de fins de ligne : ces commandes peuvent supprimer votre travail. Les fichiers binaires nécessitent une attention particulière, car la conversion des fins de ligne peut endommager les données si Git les traite comme du texte. Documentation de Git sur git-config

Définir une valeur par défaut adaptée pour macOS

Pour votre propre utilisation de Git sur l'ensemble de vos dépôts, définissez la préférence documentée pour macOS :

git config --global core.autocrlf input

Avec input, Git normalise CRLF en LF lors de l'ajout de texte, sans convertir les fichiers en LF vers CRLF lors de l'extraction (checkout). Ce paramètre ne règle pas la politique pour chaque fichier : les attributs du dépôt peuvent spécifier le comportement par type de fichier, et les attributs text et eol de Git contrôlent la normalisation et les fins de ligne à l'extraction. Recommandations de GitHub selon la plateforme et Référence de configuration de Git

Si le problème se limite à un seul projet, préférez la politique .gitattributes de ce projet plutôt que de modifier votre configuration globale pour un seul dépôt. Un point de départ courant est * text=auto ; des formats spécifiques peuvent être fixés à LF ou CRLF, tandis que les formats binaires doivent être marqués comme binary. Par exemple, les scripts shell nécessitent généralement LF, tandis que certains fichiers de projet Windows exigent CRLF. Les motifs appropriés dépendent des outils du dépôt et des collaborateurs. Exemples de gitattributes de Git

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Renormaliser uniquement après avoir examiné les modifications

La modification de la configuration ou des attributs ne garantit pas que les fichiers existants deviennent immédiatement cohérents. La procédure d'actualisation documentée par GitHub consiste d'abord à enregistrer ou valider le travail en cours, puis à exécuter git add --renormalize . et à examiner l'état qui en résulte. Instructions d'actualisation de GitHub

Après avoir enregistré vos modifications en toute sécurité et fixé la politique du dépôt, indexez la normalisation et inspectez exactement ce que Git propose :

git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached

Ne committez pas automatiquement. Examinez le diff indexé, en particulier pour les fichiers binaires inattendus ou générés. S'il affiche encore des modifications de contenu que vous n'aviez pas prévues, arrêtez-vous et inspectez les chemins concernés ainsi que leurs valeurs attr/ avec git ls-files --eol ; corrigez la politique d'attributs avant d'indexer à nouveau. La renormalisation peut produire un diff légitime volumineux si le dépôt contenait auparavant des fins de ligne incohérentes, il convient donc de coordonner un commit de normalisation avec les collaborateurs si nécessaire.

Si les fichiers restent modifiés

Les fins de ligne ne sont qu'une cause possible. Recherchez des différences de fond dans les diffs indexés ou non indexés, vérifiez si un éditeur a réécrit les fichiers et inspectez les filtres ou attributs propres à chaque fichier. Si git ls-files --eol indique i/lf et w/crlf, confirmez si un attribut ou un paramètre demande intentionnellement CRLF. S'il indique mixed, déterminez quels fichiers ont des fins de ligne mixtes et s'il s'agit bien de texte avant de normaliser. Les contrôles de sécurité de Git peuvent avertir des conversions irréversibles, mais ils ne peuvent pas savoir si un fichier a été classé à tort comme du texte. Référence de configuration de Git

La séquence pratique est la suivante : protégez vos modifications, inspectez core.autocrlf et git ls-files --eol, choisissez une politique de projet cohérente, puis renormalisez et examinez le diff. Cela permet d'éliminer le bruit lié aux fins de ligne tout en gardant le contrôle sur les modifications réelles du contenu.

Sources