Convertir les délimiteurs de fin de ligne pour utiliser Git avec Linux et Windows

Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack

Convertir les délimiteurs de fin de ligne pour utiliser Git avec Linux et Windows

Problématique

Un problème subtil et incroyablement ennuyeux généré lors de la collaboration entre différents systèmes.
Si vous développez sous Windows ou depuis un autre système d'exploitation tout en devant collaborer avec des personnes sous Windows, vous rencontrerez des problèmes de caractères de fin de ligne.
Windows utilise pour marquer les fins de ligne dans ses fichiers un caractère « retour chariot », carriage return, CR, suivi d'un caractère « saut de ligne » (line feed, LF).
Mac et Linux utilisent seulement le caractère « saut de ligne ».

Laisser une ligne blanche à la fin de chaque fichier

C'est une bonne méthode que de toujours mettre une nouvelle ligne blanche en dernier caractère si le format de fichier le permet.
De plus, pour les fichiers d'en-tête C et C ++, cette méthode est requise par le standard de langage.

Si la ligne blanche à la fin du fichier est absente, on peut voir qu'en affichant deux fois le même fichier avec cat, le deuxième affichage sera ajoutée à la "ligne" finale du premier affichage si elle ne se termine pas par une nouvelle ligne. Le code sera donc affiché bout à bout et, dans certains cas, cela pourra générer une erreur de script quand ils sont inclus dans un fichier.

Chaque fichier doit de ce fait avoir une ligne vide, simplement avec la touche entrée, qu'il soit créé depuis Linux ou Windows !
Ainsi, qu'il soit édité directement ou avec du contenu par copier coller, ajouter une fin de ligne vide permet, en plus d'être une bonne pratique, de ne pas avoir le caractère rouge en fin de fichier depuis Github : No newline at the end of file.

Configurer l'éditeur

Avec Eclipse installé sous Linux

Les équipes utilisent habituellement la version Unix, c'est cette version qu'il faudrait donc configurer par défaut. Windows et Macintosh la comprennent et la traitent bien.
Pour faire face au problème de fin de ligne souvent rencontrés lors d'un travail collaboratif sur Git entre des machines Linux et Windows, configurer Eclipse de façon globale avec le choix Unix :
Fenêtre / Général / Espace de travail / "Nouveau délimiteur de ligne du fichier texte" et choisir Unix.

Avec Eclipse installé sous Windows

Je laisse la configuration globale à Windows. La configuration de Git par après dans la page devrait permettre le bon fonctionnement des données du dépôt vers le client, et du client vers le dépôt :
Fenêtre / Général / Espace de travail / "Nouveau délimiteur de ligne du fichier texte" et choisir Windows.

Changer le type de fin de ligne pour un fichier ou dossier ou projet depuis la vue PHP de Eclipse

# Cette étape ne devrait pas être nécessaire si le dépôt est correctement configuré.
# On arrivera à obtenir un dépôt qui pourra correctement fonctionner entre Linux -> Windows / Windows -> Linux en suivant les autres recommandations de cette page.

Convertir la fin de ligne d'un fichier : Clic droit / Code source / Nettoyer le document / On peut choisir de remplacer le caractère de fin de ligne pour Unix.
Convertir la fin de ligne d'un dossier et de ses fichiers : Fichier -> "Convertir les délimiteurs de ligne en" et choisir Unix.
Convertir la fin de ligne d'un projet : Propriétés / Ressources / Nouveau délimiteur de ligne du fichier texte : Unix

Paramétrer Git au niveau global et utilisateur

Utiliser core.autocrlf dans la configuration du dépôt Git

Paramétrer un seul et unique système d'exploitation

Si plusieurs programmeur gèrent un projet spécifique sous un système unique, vous pouvez laisser cette fonctionnalité désactivée.

L'utilisation de false a pour résultat que Git ne perturbe jamais les fins de ligne de votre fichier.
Les fichiers peuvent être archivés avec LF ou CRLF ou CR ou encore avec un mélange aléatoire.
Cela peut rendre les diffs plus difficiles à lire et les fusions plus difficiles.

La plupart des développeurs travaillant dans un monde Unix / Linux utilisent cette valeur car elles n'ont pas de problèmes CRLF.
Ils n'ont pas besoin que Git fasse un travail supplémentaire chaque fois que des fichiers sont écrits dans la base de données d'objets ou dans le répertoire de travail.

Régler la valeur du paramètre à false est la valeur par défaut, mais, il est conseillé de changer cela immédiatement lors de l'initialisation du dépôt !
git config --global core.autocrlf false
git config --local core.autocrlf false

Paramétrer Linux et Mac

Ce réglage devrait donner des fins de ligne en CRLF lors d'extraction sous Windows mais en LF sous Mac et Linux et dans le dépôt.

Git traitera tous les fichiers texte et s'assurera que CRLF est remplacé par LF lors de l’écriture dans le dépôt.
Ce paramètre est généralement utilisé sous Unix / Linux / OS X pour empêcher l'écriture de CRLF dans le référentiel.
Si vous collé du code depuis un navigateur Web et que des CRLF sont accidentellement insérés dans un fichier, Git s'assure du replacement par LF lors de l'écriture dans la base de données d'objets.

Régler la valeur du paramètre à input :
git config --global core.autocrlf input
git config --local core.autocrlf input

Paramétrer Windows

Git peut convertir automatiquement les fins de ligne CRLF en LF lorsque vous déposez le code sur un dépôt distant.
Inversement Git convertira les fins de ligne de LF en CRLF lorsque vous récupérerez le code sur votre système.

Git traitera tous les fichiers texte et veillera à ce que CRLF soit remplacé par LF lors de l'écriture de ce fichier dans la base de données d'objets.
Cela reconvertira tous les fichiers LF dans CRLF lors de l'écriture dans le répertoire de travail.
Il s'agit du paramètre recommandé sous Windows car il garantit que votre référentiel puisse être utilisé sur d'autres plates-formes tout en conservant CRLF dans votre répertoire de travail.

Régler la valeur du paramètre à true :
git config --global core.autocrlf true
git config --local core.autocrlf true

Paramétrer un référentiel Git

# Il vaut mieux configurer le .gitattributes pour obtenir une bonne configuration de Git. À faire depuis Linux et Windows.
# Le fichier .gitattributes doit être créé à la racine du référentiel, au niveau du dossier .git et validé comme tout autre fichier.

# Git gérera les fichiers de la manière qui lui semble la meilleure. C'est une bonne option par défaut si core.autocrlf n'a pas été défini.
# Ceci est équivalent aux valeurs core.autocrlf défaut core.autocrlf recommandées de "input" sur Linux / macOS et "true" sur Windows.
* text=auto
#
# Déclarer explicitement les fichiers texte que vous voulez toujours convertir pour les fins de ligne lors du checkout.
*.php
*.js text
#
# Git convertira toujours les fins de ligne en `CRLF` lors du checkout. Utiliser cette option pour les fichiers qui doivent conserver les terminaisons `CRLF`, même sous OSX ou Linux.
*.bat      text eol=crlf
#
# Git convertira toujours les fins de ligne en `LF` lors du checkout. Utiliser cette option pour les fichiers qui doivent conserver les terminaisons LF, même sous Windows.
*.sh       text eol=lf
# 
#
# Pour les images notamment, Git comprendra que les fichiers spécifiés ne sont pas du texte et il ne devrait pas essayer de les modifier.
# (Le paramètre `binary` est également un alias pour` -text -diff`.)
*.png binary

# Important !
# Générateur de .gitattributes : https://gitattributes.io
# Utiliser le générateur de .gitattributes pour obtenir un modèle pour le web : https://gitattributes.io/api/web

Actualiser un référentiel après modification

# Afficher les fichiers qui ne sont pas encore commit.
git status

# Ajouter les fichiers actuels dans le référentiel Git de sorte que le travail ne soit pas perdu.
git add . -u
git commit -m "Sauvegarder vos modifications en cours"

# Supprimer tous les fichiers versionnés dans git
git rm -r --cached .

# C'est avec cette commande que git va changer toutes les EOF avec ce que l'on a spécifié dans le .gitattributes :
# Les caractères -- correspondent à la branche courante.
git checkout -- .

# Réinitialiser l'index local et sur le dépôt. ### Vérifier si cette commande est indispensable.
# git reset --hard

# Ajouter tous les fichiers modifiés en normalisant les fins de ligne.
git add --renormalize .

# Ajouter les modifications dans le référentiel.
git commit -m "git add --renormalize ."

# Tous les fichiers qui, à tort, ont été archivés avec des fins de ligne de style Windows seront désormais "renormalisés" pour avoir des fins de ligne de style Unix.

Alternatives pour changer la fin de ligne d'un fichier depuis un terminal Linux

Cette méthode n'a pas été testée en situation !
Je préfère utiliser l'interface de Eclipse pour le moment, mais, la méthode via le terminal peut être très pratique !

Le paramètre -ie de sed permet de créer un second fichier en ajoutant "e" au nom du fichier, très utile pour faire des tests.

Conversion DOS vers UNIX

Le caractère retour chariot "\r" est représenté symboliquement par "^M", qui s'obtient par la séquence de touches suivante "CTRL-V" + "CTRL-M".

Il suffit simplement d'effacer le caractère "\r" (retour chariot) de fin de ligne.
sed 's/^M$//' fichier

Avec la version GNU-sed (gsed 3.02.80 et supérieur), on peut utiliser la notation ASCII :
sed 's/\x0D$//' fichier

Un équivalent avec tr : 
tr -d '\r' < fichier1 > fichier2

Un équivalent avec perl : 
perl -p -e 's/\r$//' < dos.txt > unix.txt

Conversion UNIX vers DOS / Windows

Faire le contraire de la commande précédente.
sed 's/$/^M/' fichier

Avec la version GNU-sed (gsed 3.02.80 et supérieur), on peut utiliser la notation symbolique "\r":
sed 's/$/\r/' fichier

Un équivalent avec perl : 
perl -p -e 's/\n/\r\n/' < unix.txt > dos.txt

Microsoft 0 - GNU/Linux 1

De préférence, si vous êtes sur un server GNU/Linux, enlever de suite les utilisateurs Windows de votre dépôt ou vous allez avoir des problèmes de retour chariot à chaque fois qu'ils pousseront leurs commits sur le dépôt Git.

NAVIGATION

PARTICIPER ET PARTAGER Bienvenue sur le wiki de Amis SH. De nombreuses pages sont partagées sur ce wiki. Créer un compte utilisateur pour participer sur le wiki. Les pages présentées sur le wiki évoluent tous les jours. Certaines recherches sont peu abouties et incluent des erreurs. Utiliser la recherche interne du wiki pour trouver votre contenu. La page de discussion de Amis SH vous permet de poser vos questions. Consulter le site amis-sh.fr pour installer votre propre serveur web. Améliorer le contenu des pages avec vos retours depuis l'onglet discussion. Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique. Protéger votre système Linux ou Windows avec cette page dédiée à la sécurité.

SOUTENIR CE WIKI Soutenir le wiki avec un don en monnaie numérique : AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash OBTENIR DE LA MONNAIE NUMERIQUE Obtenir gratuitement de la monnaie numérique : Miner de la cryptomonnaie.