Git - Quelques astuces pour votre fichier .gitconfig
Personnalisez votre workflow Git avec des astuces essentielles pour le fichier ~/.gitconfig. Apprenez à créer un alias git undo, à gérer les branches distantes, à gérer les credentials et à forcer SSH.
Traduction automatique
Journal des modifications
git-credential-manager.exe, no more git-credential-manager-core.exe
Cet article partage un ensemble de personnalisations pratiques du fichier ~/.gitconfig : un alias git undo pour abandonner le dernier commit local, la création automatique des branches distantes lors d'un push, la suppression automatique des branches de suivi mortes et le tri de la sortie de git branch par date du dernier commit. Il couvre aussi le partage du Credential Manager de Windows avec WSL2, l'utilisation de credentials différents selon le dossier pour séparer travail et projets personnels, le forçage de SSH au lieu de HTTPS de façon globale, et comment empêcher Git de convertir les fins de ligne LF en CRLF sous Windows.
Dans cet article, nous allons explorer quelques astuces pour utiliser Git plus facilement en personnalisant le fichier ~/.gitconfig.
Nous allons créer une nouvelle commande git undo pour abandonner le dernier commit local.
Nous verrons comment partager le Credential Manager de Windows avec Linux, comment avoir plusieurs credentials selon la structure de vos dossiers, ...
Nous verrons également comment mieux travailler avec les branches : les trier par date de commit plutôt que par nom, supprimer automatiquement (prune) les anciennes branches ou forcer la création d'une nouvelle branch sur le remote.
Si vous utilisez Linux (ou WSL), votre fichier de configuration Git se trouve ici : ~/.gitconfig. Vous pouvez l'éditer avec vi ou VSCode (vi ~/.gitconfig ou code ~/.gitconfig).
En ligne de commande
Vous pouvez éditer votre configuration globale en lançant git config --global --edit dans la console.
L'éditeur par défaut sera démarré (vi ou peut-être nano si vous l'avez). Si vous préférez VSCode, lancez d'abord git config --global core.editor "code --wait" dans la console. Vous avez maintenant associé git à VSCode également pour, par exemple, éditer votre message de commit.
Alias
Mais combien de fois ai-je essayé un git undo pour, hop hop, effacer tout ce que j'ai fait en local et repartir du dernier commit poussé sur le repository distant.
Par exemple, je fais du refactoring et aïe, non, je ne suis pas content et je veux annuler mon dernier commit local (= j'ai fait git add ... && git commit ... mais pas git push).
Ce serait bien de pouvoir lancer git undo pour ça, non ? C'est là que la notion d'alias entre en jeu.
Ajoutez simplement les deux lignes ci-dessous dans votre ~/.gitconfig :
[alias] undo = "!f() { git reset --hard $(git rev-parse --abbrev-ref HEAD)@{${1-1}}; }; f"Ce fichier de configuration Git définit un alias personnalisé appelé 'undo' qui permet d'annuler les changements en revenant à un état antérieur du dépôt. L'alias utilise une fonction shell pour récupérer la référence de la branche courante et la réinitialiser à un commit précédent dans l'historique de reflog, avec une valeur par défaut d'une étape en arrière si aucun paramètre n'est fourni.
En ligne de commande
Au lieu de modifier le fichier à la main, vous pouvez obtenir exactement le même résultat en lançant git config --global alias.undo '!f() { git reset --hard $(git rev-parse --abbrev-ref HEAD)@{${1-1}}; }; f' dans la console.
source : https://github.com/git-tips/tips
Branches
Créer automatiquement la nouvelle branch sur le remote
Quand vous travaillez sur une nouvelle fonctionnalité, vous ferez très probablement d'abord git checkout -b myNewFeature pour créer la branch myNewFeature sur votre machine. Si vous avez souvent besoin de deux branches actives en même temps, jetez un œil à git worktree.
Ensuite vous allez coder et le moment viendra de pousser vers git avec, par exemple, git add . ; git commit -m "wip" ; git push, mais ça ne fonctionnera pas directement.
En effet, git va se plaindre que myNewFeature n'existe pas sur le remote et qu'il faut d'abord créer la branch.
Vous pouvez éviter ça en ajoutant les deux lignes ci-dessous dans votre ~/.gitconfig :
[push] autoSetupRemote = trueCette configuration Git active l'option autoSetupRemote pour les opérations push, ce qui établit automatiquement une branche de suivi sur le serveur distant quand vous poussez une branche locale pour la première fois, sans devoir spécifier explicitement la destination.
Maintenant, si la branch locale n'existe pas sur le remote, git push la créera automatiquement pour vous.
Nettoyer les branches mortes
Par défaut, git se souvient de chaque nom de branch qui a existé à un moment donné, même si la branch a été supprimée du repository distant entre-temps.
Donc, après plusieurs mois, si vous lancez git branch --list --all sur votre machine, vous pouvez obtenir des noms de branches qui n'existent plus sur le repository distant.
Ajoutez simplement les deux lignes ci-dessous dans votre fichier ~/.gitconfig pour demander à git de faire le nettoyage automatiquement lors d'un git fetch :
[fetch] prune = trueCette configuration définit le comportement de la commande fetch dans git en activant l'option prune, qui supprime automatiquement les références locales aux branches distantes qui n'existent plus sur le serveur distant.
En ligne de commande
Au lieu de modifier le fichier à la main, vous pouvez obtenir exactement le même résultat en lançant git config --global fetch.prune true dans la console.
Trier les branches sur la date du dernier commit
Au travail, nous utilisons Git sur une très grosse base de code et donc nous créons des branches pour ajouter de nouvelles fonctionnalités.
En lançant git branch --list --all (ou, en plus court, git branch -a), git renvoie la liste des branches dans l'ordre alphabétique, ce qui n'est vraiment pas très utile.
Il serait préférable de trier la liste sur le dernier commit fait dans la branch pour avoir, en haut de liste, les branches utilisées récemment et, en bas, les inactives. J'ai poussé cette idée plus loin avec un hook de shell qui les affiche automatiquement : Afficher les 3 dernières branches modifiées quand vous entrez dans un repo git.
Pour ce faire, ajoutez simplement le bloc ci-dessous dans votre fichier ~/.gitconfig :
[branch] sort = -committerdateCette configuration Git définit un ordre de tri pour les branches basé sur la date du commit, en ordre décroissant (les branches les plus récentes d'abord). C'est utile pour voir rapidement quelles branches ont été modifiées le plus récemment.
En ligne de commande
Au lieu de modifier le fichier à la main, vous pouvez obtenir exactement le même résultat en lançant git branch --sort=-committerdate dans la console.
Credentials
Partager le Credential Manager de Windows avec Linux
Si vous êtes sur WSL2, vous pouvez réutiliser les credentials que vous avez déjà saisis sur Windows. En effet, vous pouvez utiliser git à la fois dans un environnement DOS et dans une console Linux.
Pour partager les credentials entre les deux environnements, ajoutez simplement les deux lignes ci-dessous dans votre fichier ~/.gitconfig :
[credential] helper = /mnt/c/Program\\ Files/Git/mingw64/bin/git-credential-manager.exeCe fichier configure Git pour utiliser un gestionnaire de credentials spécifique. Il indique à Git d'exécuter l'executable git-credential-manager.exe pour gérer les authentifications (noms d'utilisateur, mots de passe, tokens, etc.) lors des opérations qui en ont besoin.
Utiliser plusieurs credentials sur la même machine
Comme vous le savez, lors de l'installation de Git, vous devez fournir votre nom et votre email. Ces deux informations sont fournies dans la console avec une commande comme celle ci-dessous :
Mais ce n'est pas très pratique quand vous travaillez sur plusieurs types de projets, par exemple pour le travail et pour vos projets personnels. Disons que vous mettez le travail professionnel dans un dossier parent comme ~/work_repositories tandis que vos projets perso sont dans ~/private_repositories.
Quand votre ~/.gitconfig ressemble à ce qui suit, chaque fois que vous pousserez vers Git, le commit publié viendra de me@work.be.
[user]
email = me@work.be
name = Christophe Avonture
Ce fichier de configuration définit les paramètres utilisateur pour le système. Il spécifie l'adresse email et le nom associés au compte utilisateur.
Et, avec la configuration ci-dessous, si vous poussez un repository situé dans ~/private_repositories, cette fois l'auteur sera me@private.be ; plus votre email professionnel.
[user] email = me@work.be name = Christophe Avonture
[includeIf "gitdir:~/private_repositories/"] email = me@private.beCe fichier configure Git avec deux profils d'email différents selon le répertoire de travail. Le profil par défaut s'applique à tous les projets, tandis que le profil conditionnel remplace l'email pour les dépôts situés dans le répertoire ~/private_repositories/.
Forcer SSH au lieu de HTTPS
Même si vous avez cloné un repository avec git clone https://..., vous pouvez forcer globalement l'utilisation de SSH à la place.
Ainsi, par exemple, si vous avez cloné votre projet avec git clone https://github.com/you/your_repo.git (https donc), chaque fois que vous pousserez, on vous demandera peut-être votre login et votre mot de passe. Vraiment pénible.
Mais si vous avez déjà créé une clé SSH pour votre profil Github, alors vous pouvez arrêter d'utiliser https et forcer SSH en ajoutant les deux lignes ci-dessous dans votre ~/.gitconfig :
[url "git@github.com"] insteadOf = https://github.com/Cette configuration Git remplace automatiquement les URLs HTTPS vers GitHub par des URLs SSH. Quand tu clones ou tu fais un push vers un dépôt GitHub en utilisant une URL HTTPS, Git utilisera à la place une connexion SSH avec ta clé privée, ce qui évite de devoir entrer ton mot de passe à chaque fois.
En ligne de commande
Vous pouvez éditer votre configuration globale en lançant git config --global url.'git@github.com:'.insteadOf 'https://github.com/' dans la console.
Dès à présent, même si le repository est toujours configuré pour utiliser https (comme vous pouvez le vérifier dans le fichier .git/config de ce projet sur votre disque dur), vous avez forcé SSL globalement.
Empêcher le remplacement automatique de LF par CRLF
Si vous travaillez sous Windows et non sous Linux/WSL, git, sous Windows, essaiera toujours de remplacer le caractère LF par CRLF et c'est vraiment très mauvais.
Ne l'autorisez pas en ajoutant l'élément de configuration suivant dans votre ~/.gitconfig :
[core] autocrlf = falseC'est un fichier de configuration Git qui désactive la conversion automatique des sauts de ligne entre les formats Windows (CRLF) et Unix (LF). Le paramètre autocrlf = false signifie que Git ne modifiera jamais les sauts de ligne dans tes fichiers, peu importe le système d'exploitation utilisé.
En ligne de commande
Vous pouvez éditer votre configuration globale en lançant git config --global core.autocrlf false dans la console.
Les fins de ligne ne sont pas la seule différence Windows/Linux à surveiller : la sensibilité à la casse des noms de fichiers en est une autre qui peut provoquer silencieusement des conflits quand le même dossier est partagé entre les deux systèmes.
