3.10 : Git en interface graphique : quel client choisir ?

Pourquoi nous avons commencé au terminal

Vous venez de passer neuf leçons en ligne de commande. C’était volontaire, pour trois raisons.

Les commandes épousent le modèle mental. git add correspond au plateau de montage, git commit au registre. Une interface graphique masque cette mécanique — très confortable quand on l’a comprise, franchement déroutante avant.

Sur un serveur, il n’y a pas d’interface. Les sections 6 et 8 se passeront intégralement en SSH sur des machines Debian.

Toute l’aide disponible est en commandes. Les forums, la documentation, l’annexe des catastrophes de cette formation : ce sont des lignes de commande. Savoir les lire n’est pas optionnel.

Cela dit, une fois ces bases acquises, rien ne vous oblige à rester au terminal. J’ai appris ainsi, et j’utilise aujourd’hui un client graphique au quotidien. Il n’y a aucun mérite à s’en priver.


Ce qu’une interface graphique fait mieux

Trois choses, et elles ne sont pas anodines.

Lire un diff. Deux colonnes côte à côte, en couleur, avec le défilement synchronisé : c’est objectivement supérieur à un affichage en terminal, surtout sur un fichier de configuration long.

Composer un enregistrement. Cocher les fichiers, voire les blocs, d’un clic. C’est le git add -p de la leçon 3.3, en plus rapide et plus lisible.

Comprendre un historique ramifié. Un graphe dessiné vaut mieux qu’un graphe en caractères ASCII dès qu’il y a plus de deux branches.