Personnalisation du comportement de Git : configuration, alias et fichiers importants

Personnaliser le comportement de Git vous aide à rendre le contrôle de version quotidien plus rapide, plus sûr et plus prévisible. Avec la bonne configuration Git, les bons alias et les fichiers importants en place, votre flux de travail local peut correspondre à la façon dont votre équipe construit réellement les logiciels.

L'objectif n'est pas de créer une configuration astucieuse que personne d'autre ne comprend. L'objectif est de supprimer les frictions des tâches courantes tout en gardant vos référentiels faciles à auditer et à prendre en charge.

Comment fonctionne la configuration Git

Git lit les paramètres de plusieurs endroits, et le paramètre le plus proche l'emporte. Cela compte lorsque vous dépannez pourquoi Git utilise le mauvais nom, éditeur, outil de fusion, fins de ligne ou comportement de signature.

Les trois principales portées de configuration sont :

Système : s'applique à chaque utilisateur sur la machine.
Globale : s'applique à votre compte utilisateur.
Locale : s'applique uniquement au référentiel actuel.

Vous travaillerez généralement avec les paramètres globaux et locaux. Les paramètres globaux sont bons pour votre identité, votre éditeur par défaut et les alias courants. Les paramètres locaux sont meilleurs pour le comportement spécifique au référentiel, comme une adresse e-mail différente pour les projets professionnels.

Utilisez ces commandes pour inspecter d'où vient un paramètre :

git config --list --show-origin
git config user.email
git config --local user.email
git config --global user.email

Par exemple, vous pouvez utiliser votre e-mail personnel de manière globale :

git config --global user.name "Alex Morgan"
git config --global user.email "[email protected]"

Ensuite, dans un référentiel professionnel, remplacez uniquement l'e-mail :

git config --local user.email "[email protected]"

Cela évite de valider accidentellement dans un référentiel d'entreprise avec une identité personnelle. Cela rend également l'historique des validations plus propre pour la conformité, la propriété et la revue de code.

Si vous souhaitez un rappel plus approfondi sur les paramètres d'identité, consultez maîtriser la configuration utilisateur Git.

Paramètres utiles à personnaliser en premier

Commencez par les paramètres qui améliorent la clarté et évitent les petites erreurs. Vous n'avez pas besoin d'un énorme fichier de configuration pour obtenir une réelle valeur.

Une bonne base de référence inclut votre nom de branche par défaut :

git config --global init.defaultBranch main

Définissez votre éditeur préféré pour que Git puisse ouvrir les messages de validation, les plans de rebasage et les notes de fusion dans un outil que vous utilisez réellement :

git config --global core.editor "code --wait"

Si vous travaillez sur macOS, Linux et Windows, les fins de ligne méritent une attention particulière. De nombreuses équipes choisissent de normaliser les fins de ligne dans le référentiel et de laisser l'éditeur de chaque développeur gérer l'affichage. Un paramètre Windows courant est :

git config --global core.autocrlf true

Sur macOS ou Linux, les équipes utilisent souvent :

git config --global core.autocrlf input

Ne modifiez pas les paramètres de fin de ligne à la légère dans un référentiel existant. Si vous voyez un énorme diff où chaque ligne semble modifiée, arrêtez-vous et inspectez .gitattributes avant de valider.

Vous pouvez également rendre la sortie de Git plus lisible :

git config --global color.ui auto
git config --global column.ui auto
git config --global branch.sort -committerdate
git config --global tag.sort version:refname

Pour tirer les modifications, choisissez le comportement attendu par votre équipe :

git config --global pull.rebase false

ou :

git config --global pull.rebase true

Aucune option n'est universellement correcte. Les pulls basés sur la fusion préservent les validations de fusion. Les pulls basés sur le rebasage maintiennent un historique local linéaire. L'important est de choisir intentionnellement et de documenter les attentes de l'équipe.

Créer des alias Git qui font gagner du temps

Les alias Git transforment les longues commandes en raccourcis courts et mémorables. Ils sont particulièrement utiles pour les commandes que vous exécutez plusieurs fois par jour.

Voici des alias pratiques qui restent lisibles :

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"

Après cela, git st vous donne le statut et git unstage file.txt supprime un fichier de la zone de staging sans toucher à votre copie de travail.

Les alias de journal sont ceux dont de nombreuses équipes tirent le plus de valeur :

git config --global alias.lg "log --oneline --decorate --graph --all"

Maintenant, vous pouvez exécuter :

git lg

Cela vous donne un graphique compact des branches, des tags et des validations. C'est utile avant de rebaser, de fusionner ou de nettoyer les branches locales.

Gardez les alias suffisamment simples pour qu'un coéquipier puisse deviner ce qu'ils font. Un alias comme git save pourrait signifier valider, stasher ou autre chose selon la personne qui l'a créé. Un alias comme git unstage est évident.

Vous pouvez consulter vos alias avec :

git config --global --get-regexp '^alias\.'

Pour plus d'exemples, consultez créer des alias Git personnalisés.

Fichiers Git importants que vous devriez connaître

Le comportement de Git n'est pas contrôlé uniquement par git config. Plusieurs fichiers du référentiel façonnent ce qui est suivi, ignoré, normalisé et protégé.

Le fichier le plus courant est .gitignore. Il indique à Git quels fichiers non suivis ignorer. Les entrées typiques incluent les sorties de build, les fichiers d'environnement locaux, les dossiers d'éditeur et les caches de dépendances :

node_modules/
dist/
.env
.DS_Store

Soyez prudent avec les motifs larges. Ignorer *.json pourrait cacher des fichiers générés, mais peut aussi cacher une configuration importante. Dans la mesure du possible, ignorez des répertoires ou des noms de fichiers spécifiques.

Le fichier .gitattributes contrôle la façon dont Git traite les types de fichiers. Il est utile pour les fins de ligne, les fichiers générés, le comportement de linguist et les stratégies de fusion :

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

Ceci est particulièrement utile dans les équipes utilisant différents systèmes d'exploitation. Cela réduit les diffs bruyants et empêche les scripts de se casser à cause de mauvaises fins de ligne.

Le fichier .git/config stocke la configuration du référentiel local. Vous l'éditez normalement avec git config --local, mais le lire peut vous aider à dépanner les dépôts distants, le suivi des branches et les options spécifiques au référentiel.

Les hooks Git se trouvent sous .git/hooks/. Ils peuvent exécuter des scripts avant les validations, les pushs, les fusions et d'autres événements. Par défaut, les hooks sont locaux et ne sont pas validés en tant que scripts actifs. Les équipes qui comptent sur les hooks utilisent souvent un script d'installation ou un gestionnaire de hooks pour les installer de manière cohérente.

Quand demander de l'aide

La plupart des modifications de configuration Git sont sûres, mais certaines peuvent perturber une équipe si elles sont appliquées sans contexte. Demandez à un ingénieur senior, un ingénieur DevOps ou un propriétaire de référentiel avant de modifier les règles de fin de ligne, les pilotes de fusion, les exigences de signature ou le comportement des hooks partagés.

Vous devriez également demander de l'aide si des validations apparaissent avec la mauvaise identité dans un référentiel protégé. Corriger les métadonnées de l'auteur après que le code a été poussé peut nécessiter une réécriture de l'historique, ce qui affecte tous ceux qui utilisent cette branche.

Si Git se comporte soudainement différemment, commencez par git config --list --show-origin. Cette seule commande explique souvent le mystère plus rapidement que de deviner.

Une personnalisation réfléchie rend Git moins répétitif sans cacher ce qui se passe. Gardez vos alias clairs, documentez les règles du référentiel et utilisez les paramètres locaux lorsqu'un projet a besoin d'un comportement différent du reste de votre machine.