Publié par

Il y a 3 années -

Temps de lecture 5 minutes

Git Essentials – 3 – les alias

git essentials logo

Ceci est le troisième article d’une série consacrée aux commandes de Git, le système de gestion de révisions décentralisé. Le sujet de cet article est le fonctionnement du système d’alias proposé par Git, qui permet de mémoriser les commandes complexes ou longues sous une forme plus simple.

Retrouvez les précédents articles de la série :

Tout comme les alias Bash ou autres shell récents, Git founit un système d’alias parfaitement intégré qui bénéficie de l’autocomplétion des commandes Git normales.

Les alias c’est bien, mais d’abord, pourquoi utiliserais-je la ligne de commande ?

À l’heure où de nombreuses interfaces graphiques pour Git existent, que ce soit sous forme de greffon (plugin) dans l’EDI ou de logiciel indépendant, on peut s’interroger sur l’intérêt d’utiliser Git en ligne de commande. Pour commencer, l’interface de Git en ligne de commande est extrêmement bien faite : les commandes disposent d’une très bonne auto-complétion, qui fonctionne sur les commandes, options et arguments, la documentation intégrée est très bien faite, avec de nombreux exemples. En dehors de cela, il y a trois principaux avantages à utiliser l’interface de Git en ligne de commande :

  • comprendre ce que l’on fait : les interfaces graphiques masquent les options réellement utilisées lorsque Git est appelé ;
  • avoir accès à toute la puissance de Git : les interfaces graphiques proposent un nombre limité de possibilités ;
  • maitriser l’interface en ligne de commande permettra de se débrouiller sur tous les OS, y compris à distance (SSH) lorsqu’aucune interface graphique n’est disponible.

Toutefois, comme les commandes Git disposent de nombreuses options combinables, certaines commandes peuvent devenir longues. Si elles sont utilisées régulièrement, pouvoir mémoriser leur forme complète et les appeler avec une forme plus courte, c’est-à-dire un alias, sera bien pratique.

Le fonctionnement

Comme expliqué plus haut, le principe de l’alias est de permettre d’exécuter une (ou des) commande(s) longue(s) sans avoir à taper la commande complète, mais plutôt un nom raccourci. Le type d’alias le plus connu est l’alias shell (Bash). Dans de nombreuses distributions GNU/Linux, certains sont disponibles par défaut, comme par exemple l’alias ll pour ls -l, commande permettant de lister les fichiers d’un répertoire sous forme longue avec de nombreuses informations. Ainsi, taper ll revient à utiliser ls -l. Les alias Bash sont définis dans l’un des fichiers de préférences utilisateur Bash, comme le fichier ~/.bashrc.

Avec Git, le principe est le même : les alias sont définis dans l’un des fichiers de préférences git, généralement le ~/.gitconfig. Pour ajouter un alias, la première méthode est d’utiliser la commande adéquate :

git config --global alias.p push

Explication :

  • config est la commande qui permet d’interagir avec la configuration de Git ;
  • --global est l’option de config qui spécifie que la configuration que nous sommes en train de modifier est globale à la machine, par opposition à un projet Git donné ;
  • alias est la section de configuration concernée ;
  • p est la clé de configuration à ajouter, ou le nom de l’alias ;
  • push est la commande git aliasée, c’est-à-dire la commande qui sera appelée lorsque l’alias sera utilisé.

Le résultat est qu’à présent, nous pourrons utiliser git p en lieu et place de git push, donc en continuant à bénéficier des options et auto-complétion de push.

Comme toutes les options de configurations, les alias sont stockés dans le fichier de configuration de l’utilisateur : ~/.gitconfig. Après la commande précédente, mon fichier ressemble à :

[user]
    name = bbonnet
    email = bbonnet@test.com
[push]
    default = simple
[color]
    ui = auto
[alias]
    p = push

En observant la structure de ce fichier, on peut aisément deviner la deuxième méthode pour créer un alias : écrire une nouvelle ligne dans la section alias.

Exemples

Nous pouvons donc ajouter quelques alias pour raccourcir des commandes de base :

[alias]
 p = push
    co = checkout
    b = branch
    st = status
    s = status -s
    a = add
    ci = commit

Ensuite, créons un alias permettant de visualiser le graphe le l’historique des commits sous forme synthétique :

[alias]
 …
 lg = log --graph --oneline --decorate --all

L’explication de ces différentes options se trouve dans l’article dédié à la commande log.

Autre raccourci utile : un alias permettant d’effectuer un pull avec un rebase au lieu d’un merge, et ainsi de conserver un graphe de commit linéaire et simple à lire :

[alias]
 …
 pullr = pull --rebase=preserve

L’explication du détail de cette commande, du fonctionnement de pull et son rapport avec merge et rebase sera expliqué en détail dans un prochain article.

Terminons avec un dernier exemple correspondant à un cas d’utilisation courant : visualiser les changements apportés par un commit. La commande git diff permet de le faire, mais pas de manière idéale. En effet, même si deux lignes ne diffèrent que d’un ou quelques caractères, la sortie de la commande affichera plusieurs lignes de contexte, et les deux versions de la ligne concernée l’une en dessous de l’autre. git diff possède une option intéressante pour effectuer un diff dont la granularité est le mot et non plus la ligne complète :

[alias]
 …
 diffw = diff --color-words

Il est possible de réduire encore la verbosité du diff en supprimant les lignes de contexte et donnant une définition du mot plus stricte :

[alias]
 …
 d = diff --unified=0 --ignore-space-at-eol --color-words='[[:alnum:]]+|[^[:space:]]'

L’explication du détail de cette commande fera partie d’un prochaine article dédié à la visualisation des différences sous Git.

Conclusion

Nous avons vu comment abréger les commandes Git courantes ou complexes. À présent, plus d’excuses pour ne pas utiliser Git en ligne de commande et accéder sans restriction à toutes les possibilités offertes par ce fabuleux outil de gestion de révisions !

À bientôt pour le prochain article de cette série !

Publié par

Publié par Bastien Bonnet

Bastien est un développeur disposant de 4 ans d'expérience. Il est passionné par le développement de logiciel de qualité (code clair, facile à maintenir, robuste face aux régression (tests automatisés)). Agiliste convaincu, il s'inscrit parfaitement dans le mouvement du software craftsmanship. Il est convaincu et investi dans le partage de connaissance pour améliorer le niveau technique et les compétences de son équipe.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.