--- UPDATE 3 --- (n'entre pas en conflit avec UPDATE 2)
Étant donné que les utilisateurs de Windows préfèrent travailler sur CRLF
et les utilisateurs de Linux / Mac préfèrent travailler sur des LF
fichiers texte. Fournir la réponse du point de vue d'un mainteneur de référentiel :
Pour moi, la meilleure stratégie (moins de problèmes à résoudre) est de conserver tous les fichiers texte avec LF
git repo à l' intérieur même si vous travaillez sur un projet Windows uniquement. Ensuite, donnez aux clients la liberté de travailler sur le style de fin de ligne de leur préférence , à condition qu'ils choisissent une core.autocrlf
valeur de propriété qui respectera votre stratégie (LF au dépôt) tout en préparant les fichiers à valider.
La mise en scène est ce que beaucoup de gens confondent lorsqu'ils essaient de comprendre comment fonctionnent les stratégies de nouvelle ligne . Il est essentiel de comprendre les points suivants avant de choisir la valeur correcte pour la core.autocrlf
propriété:
- Ajout d' un fichier texte pour Commit ( mise en scène il) est comme la copie du fichier à un autre endroit dans le
.git/
sous-répertoire avec fins de ligne convertis ( en fonction de la core.autocrlf
valeur de votre configuration client). Tout cela se fait localement.
- paramètre
core.autocrlf
est comme fournir une réponse à la question (exactement la même question sur tous les OS):
- "Doit git-client a. Convertir LF-en-CRLF lors de l'extraction (tirer) le repo change de la télécommande ou b. Convertir CRLF-en-LF lors de l'ajout d'un fichier à valider? " Et les réponses possibles (valeurs) sont:
false:
" ne faites rien de ce qui précède ",
input:
" faire seulement b "
true
: " faire a et b "
- notez qu'il n'y a PAS de " ne faire qu'un "
Heureusement
- Les valeurs par défaut du client git (windows
core.autocrlf: true
:, linux / mac:)
core.autocrlf: false
seront compatibles avec la stratégie LF-only-repo .
Signification : les clients Windows seront par défaut convertis en CRLF lors de l'extraction du référentiel et convertis en LF lors de l'ajout pour validation. Et les clients Linux ne feront par défaut aucune conversion. Ceci conserve théoriquement votre dépôt uniquement.
Malheureusement:
- Il peut y avoir des clients GUI qui ne respectent pas la
core.autocrlf
valeur git
- Il peut y avoir des gens qui n'utilisent pas de valeur pour respecter votre stratégie de lf-repo. Par exemple, ils utilisent
core.autocrlf=false
et ajoutent un fichier avec CRLF pour la validation.
Pour détecter les fichiers texte non lf ASAP commis par les clients ci-dessus, vous pouvez suivre ce qui est décrit sur --- mise à jour 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD
, sur un client compilé en utilisant: --with-libpcre
flag)
Et est le piège ici: . En tant que mainteneur de pension, je gardegit.autocrlf=input
afin de pouvoir corriger tous les fichiers mal validés simplement en les ajoutant à nouveau pour la validation. Et je fournis un texte de validation: "Correction des fichiers mal validés".
Autant .gitattributes
qu'on le comprend. Je ne compte pas là-dessus, car il y a plus de clients ui qui ne le comprennent pas. Je ne l'utilise que pour fournir des conseils pour le texte et les fichiers binaires, et peut-être signaler certains fichiers exceptionnels qui devraient partout garder les mêmes fins de ligne:
*.java text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg -text # Don't do auto-detection. Treat as binary
*.sh text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat text eol=crlf # Treat as text. Checkout and add with eol=crlf
Question: Mais pourquoi sommes-nous intéressés par la stratégie de gestion de la nouvelle ligne?
Réponse: pour éviter une validation de modification d' une seule lettre, apparaissez comme une modification de 5000 lignes , simplement parce que le client qui a effectué la modification a automatiquement converti le fichier complet de crlf en lf (ou l'inverse) avant de l'ajouter pour la validation. Cela peut être assez douloureux en cas de résolution de conflit . Ou cela pourrait dans certains cas être la cause de conflits déraisonnables.
--- MISE À JOUR 2 ---
Les dafaults de git client fonctionneront dans la plupart des cas. Même si vous n'avez que des clients Windows uniquement, des clients Linux uniquement ou les deux. Ceux-ci sont:
- Windows:
core.autocrlf=true
signifie convertir les lignes en CRLF à la caisse et convertir les lignes en LF lors de l'ajout de fichiers.
- linux:
core.autocrlf=input
signifie ne pas convertir les lignes à la caisse (pas besoin car les fichiers devraient être validés avec LF) et convertir les lignes en LF (si nécessaire) lors de l'ajout de fichiers. ( - update3 - : Il semble que ce soit false
par défaut, mais encore une fois, ça va)
La propriété peut être définie dans différentes étendues. Je suggère de définir explicitement la --global
portée, pour éviter certains problèmes IDE décrits à la fin.
git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf
Je déconseille également fortement l' utilisation sur Windows git config --global core.autocrlf false
(au cas où vous avez uniquement des clients Windows) contrairement à ce qui est proposé pour la documentation Git . La valeur false va valider les fichiers avec CRLF dans le référentiel. Mais il n'y a vraiment aucune raison. Vous ne savez jamais si vous devrez partager le projet avec des utilisateurs Linux. De plus, c'est une étape supplémentaire pour chaque client qui rejoint le projet au lieu d'utiliser les valeurs par défaut.
Maintenant, pour certains cas particuliers de fichiers (par exemple *.bat
*.sh
) dont vous souhaitez qu'ils soient extraits avec LF ou avec CRLF, vous pouvez utiliser.gitattributes
Pour résumer, la meilleure pratique est:
- Assurez-vous que chaque fichier non binaire est validé avec LF sur git repo (comportement par défaut).
- Utilisez cette commande pour vous assurer qu'aucun fichier n'est validé avec CRLF:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
( Remarque: sur les clients Windows ne fonctionne que via git-bash
et sur les clients Linux uniquement s'ils sont compilés à l'aide de --with-libpcre
in ./configure
).
- Si vous trouvez de tels fichiers en exécutant la commande ci-dessus, corrigez-les. Cela implique (au moins sur Linux):
- définir
core.autocrlf=input
( --- mise à jour 3 - )
- changer le fichier
- annuler la modification (le fichier est toujours affiché comme modifié)
- engagez-le
- N'utilisez que le strict minimum
.gitattributes
- Demandez aux utilisateurs de définir ce qui est
core.autocrlf
décrit ci-dessus sur ses valeurs par défaut.
- Ne comptez pas à 100% sur la présence de
.gitattributes
. Les clients git des IDE peuvent les ignorer ou les traiter différemment.
Comme dit, certaines choses peuvent être ajoutées dans les attributs git:
# Always checkout with LF
*.sh text eol=lf
# Always checkout with CRLF
*.bat text eol=crlf
Je pense que d'autres options sûres pour .gitattributes
au lieu d'utiliser la détection automatique pour les fichiers binaires:
-text
(par exemple pour *.zip
ou *.jpg
fichiers: ne sera pas traité comme du texte. Par conséquent, aucune conversion de fin de ligne ne sera tentée. Des différences pourraient être possibles grâce aux programmes de conversion)
text !eol
(par exemple *.java
, *.html
:. Donc paramètre client est utilisé traité comme du texte, mais la préférence de style EOL n'est pas réglé.)
-text -diff -merge
(par exemple pour *.hugefile
: Non traité comme du texte. Aucune différence / fusion possible)
--- MISE À JOUR PRÉCÉDENTE ---
Un exemple douloureux d'un client qui commettra des fichiers à tort:
netbeans 8.2 (sous Windows), commettra à tort tous les fichiers texte avec des CRLF, sauf si vous l'avez explicitement défini core.autocrlf
comme global . Cela contredit le comportement standard du client git et cause beaucoup de problèmes plus tard lors de la mise à jour / fusion. C'est ce qui rend certains fichiers différents (bien qu'ils ne le soient pas) même lorsque vous revenez .
Le même comportement dans les netbeans se produit même si vous avez ajouté correctement.gitattributes
à votre projet.
L'utilisation de la commande suivante après un commit vous aidera au moins à détecter tôt si votre dépôt git a des problèmes de fin de ligne: git grep -I --files-with-matches --perl-regexp '\r' HEAD
J'ai passé des heures à trouver la meilleure utilisation possible .gitattributes
, pour enfin réaliser que je ne peux pas compter là-dessus.
Malheureusement, tant qu'il existe des éditeurs basés sur JGit (qui ne peuvent pas gérer .gitattributes
correctement), la solution sûre est de forcer LF partout même au niveau de l'éditeur.
Utilisez les anti-CRLF
désinfectants suivants .
.gitattributes
?