Licence CC BY

Git : la GUI est votre amie !

Les avantages d'utiliser une interface graphique pour piloter Git

Si vous utiliser Git, il est probable qu’un jour vous vous soyez posé une question existentielle quant à la manière de réaliser telle ou telle manipulation. Et il est tout aussi probable qu’au cours de vos recherches vous soyez tombés sur une réponse du type :

Facile, il suffit de lancer git bidule --option en ligne de commande.

Souvent sans plus d’information. Parfois ça résout le problème, parfois non, et dans bien des cas vous n’avez tout simplement pas compris ce que vous venez de faire.

Le souci ici, c’est que beaucoup d’utilisateurs de Git, en particulier d’utilisateurs avancés (et donc susceptibles d’aider sur Internet) sont des aficionados de la ligne de commande et sont persuadés que celle-ci est nécessaire pour utiliser Git, voire parfois indispensable pour bien le comprendre.

Je suis quant à moi convaincu que passer par une interface graphique aide beaucoup à comprendre et utiliser Git, et je vais vous expliquer pourquoi.

Oh, et un point de vocabulaire :

  • CLI = interface en ligne de commandes (Command Line Interface dans la langue de Iron Maiden)
  • GUI = interface graphique (Graphical User Interface dans la langue de Tool)

Mon expérience avec Git

Un peu d’historique pour que vous compreniez pourquoi je vais tenir cette position. J’ai réellement commencé à utiliser Git assez tard, en 2014 avec… la création de Zeste de Savoir.

Un an plus tard, dans mon entreprise, j’avais démontré qu’en passant de SVN à Git, on passait d’une demi-journée de checkout à l’initialisation du projet géant à moins d’une demi-heure, sans perdre l’historique. J’étais propulsé « référent Git » et chargé de mettre en place la migration SVN → Git sur les projets qui en avaient besoin et sur les nouveaux dépôts. Ceci incluait la formation initiale et le suivi des équipes.

Rebelote à partir de 2018, où ma nouvelle entreprise voulait passer à Git (et avait commencé à le faire), mais était perdue par manque de connaissance des outils.

Donc, ce que je vais vous présenter ensuite n’est pas une pure théorie sortie de mon chapeau. C’est quelque chose qui a servi à des dizaines de développeurs professionnels qui utilisent Git au quotidien maintenant. C’est quelque chose que j’ai expérimenté et qui fonctionne avec le plus grand nombre, même si comme toute méthode elle a connu son petit lot d’exceptions.

D’autre part, je ne suis pas anti-CLI dans l’absolu. Au contraire, je fais toute mon administration en ligne de commandes (celle de mon poste, celle de mes serveurs personnels et celle des serveurs dont j’ai la responsabilité dans mon entreprise). Mais ça n’implique pas que j’utilise la ligne de commande pour tout et n’importe quoi : elle est plus pratique dans certains contextes et non dans l’absolu.

Les problèmes avec la CLI

Un manque d’information

Le problème d’une interface en ligne de commandes, c’est que ça manque de contexte. Genre, beaucoup.

Admettons pour l’exemple que je viens de préparer une évolution sur la Gateway de Spring-Cloud, et que j’aie des retours sur ma merge request. Je fais donc mes petites modifications et je veux les commiter. En arrivant sur la ligne de commande, j’ai précisément ceci :

Si je suis un développeur amateur de ligne de commande, j’ai peut-être configuré mon terminal avec zsh et un outil pour afficher directement des informations Git dans l’invite de commande, auquel cas j’aurai quelque chose comme ceci :

On a déjà un peu plus d’informations, mais ce n’est pas folichon. En particulier, sans rien faire, je ne sais pas :

  • Quels sont les fichiers ajoutés (qu’ils soient ajoutés à l’index Git ou non), modifiés ou supprimés.
  • Quel est l’état des branches distantes. Par exemple, aucune de ces captures d’écran ne montre que j’ai déjà fetch les dépôts distants, que master a avancé et donc que j’ai probablement du rebase à prévoir.
  • Quelles sont les différences entre les versions commitées et non-commitées à l’intérieur de chaque fichier.
  • À quoi ressemble l’arbre de commits, utile pour savoir ce qu’il s’est passé sur le dépôt et surtout quasiment indispensable pour comprendre certaines opérations comme rebase.
  • Quelles sont mes branches locales (et les branches distantes, mais l’intérêt est souvent moins immédiat).

Et à moins d’avoir spécialement configuré mon terminal, je ne sais pas non plus :

  • Quelle est la branche courante.
  • S’il y a un dépôt Git dans le chemin en cours.
  • S’il y a des fichiers non comités dans ce dépôt.

Une double connaissance est requise pour aller plus loin

L’autre souci de la CLI, c’est que son utilisation nécessite un double connaissance. L’utilisateur doit savoir :

  1. Ce qu’il veut faire fonctionnellement.
  2. La syntaxe exacte de la commande qui permet d’y arriver.

Or, retenir une syntaxe est généralement plus compliqué que de retenir l’emplacement d’un bouton dans une interface graphique. Et si certaines commandes sont rapides à taper, d’autres n’ont pas cet avantage. C’est d’autant plus complexe avec Git, qui a généralement plusieurs commandes pour arriver au même résultat, avec souvent deux ensembles : les commandes plumbing d’assez bas niveau surtout destinées aux scripts, et les commandes porcelain destinées plutôt aux humains.

Pire : contrairement à une interface graphique, il ne suffit pas de regarder un peu partout pour espérer trouver si on ne connait pas la syntaxe. Il faut soit aller chercher la documentation, soit de l’aide (sur Internet ou auprès de collègues).

Enfin, la CLI de Git permet par essence de réaliser toutes les opérations possibles et imaginables. Mais notez bien qu’elle ne permet pas de réaliser simplement toutes ces opérations – et n’en a d’ailleurs pas la prétention.

Les conséquences pratiques

Les conséquences de tout ça, c’est que si la CLI de Git permet littéralement de tout faire, son ergonomie et ses contraintes impliquent :

  • Un risque accru d’erreurs, principalement par méconnaissance de ce que fait réellement une commande.
  • Une perte de temps :
    • Par des opérations rendues complexes par la ligne de commande.
    • À cause du manque d’informations, qui ne permet pas de vérifier en temps réel ce qu’on fait.

Pourquoi une interface graphique est l’amie de Git

Tout, d’un coup d’œil, à portée d’un clic (ou deux)

Le premier avantage d’une interface graphique pour utiliser Git, c’est qu’on a toutes les informations disponibles en même temps, ou au pire à un clic.

Si je reprends mon exemple de la section précédente et que cette fois j’utilise le client Git intégré à IntelliJ 2020.1, j’obtiens ceci :

OK, c’est un peu chargé, mais on va détailler. Ici je suis sur un client en particulier, mais n’importe quel bon client graphique Git présentera aussi toutes ces informations, quoique pas exactement sous cette forme.

Je reprends la liste des « informations que je n’ai pas » de la section précédente.

Mes fichiers ajoutés/modifiés/supprimés

Ils sont présentés ici :

Pour avoir l’information en CLI, il aurait fallu taper :

$ git status

Les branches locales et distantes

Pour avoir l’information en CLI, il aurait fallu taper :

$ git branch -a

Les différences entre les versions commitées et non-commitées de chaque fichier

Ici il me suffit de cliquer sur un fichier de la liste pour voir les différences :

Pour avoir l’information en CLI, il aurait fallu taper :

$ # Donne le diff d’un seul fichier, il faut taper son chemin :
$ git diff docs/src/main/asciidoc/spring-cloud-gateway.adoc
$ # Donne le diff de tout le commit, avec une ergonomie que je vous laisse juger
$ git diff

Je ne sais pas vous, mais moi je comprends beaucoup mieux le diff de l’interface graphique que celui de la CLI.

L’arbre de commits

Non seulement il est affiché de façon lisible, mais en plus il suffit de cliquer sur un commit pour savoir quels sont les fichiers impactés, et de double-cliquer sur un fichier pour avoir le diff exact.

Pour avoir l’information en CLI, il aurait fallu taper :

$ git log --graph --oneline --all # Pour l’arbre seulement
$ git show --name-only 77a301e0 # Pour la liste des fichiers impactés par un commit

On remarque que lister les fichiers impactés par un commit nécessite de connaitre l’identifiant de ce dernier.

La branche courante

Elle est indiquée en bas de la zone de saisie du message de commit, avec en prime le résumé des fichiers qui vont être commités.

Pour avoir l’information en CLI, il aurait fallu taper :

$ git diff docs/src/main/asciidoc/spring-cloud-gateway.adoc
$ git show-branch                 # Renvoie le nom de la branche courante, entre autres
$ git rev-parse --abbrev-ref HEAD # Renvoie uniquement le nom de la branche courante, la syntaxe n’est pas intuitive
$ git branch --show-current       # Référencé sur Internet mais ne fonctionne pas avec Git 2.20.1

Et surtout, j’ai toutes ces informations sur le même écran, sans avoir besoin de penser à les chercher !

Les actions, mêmes complexes, à portée d’un ou deux clics

Je ne détaillerai pas plus que ça parce que les actions possibles dépendent du client graphique exact que vous utilisez.

Mais quel que soit votre GUI, les principales actions Git seront disponibles en un ou deux clics – ou un ou deux raccourcis claviers, si vous préférez ce mode d’entrée. Je pense notamment, mais pas que, à :

  • Sélectionner/désélectionner un fichier pour le commiter.
  • Commiter (dont « modifier un commit » avec amend)
  • Pousser sur un serveur
  • Récupérer les informations du serveur
  • Merger une branche sur une autre
  • Rebase
  • Squash

Les bonnes interfaces graphiques permettent aussi de faire facilement des actions pénibles à réaliser avec la CLI. Celle que j’utilise le plus, c’est le commit partiel d’un fichier. Si les versions de Git récentes ont git commit --interactive, les clients graphiques ont tout simplement des cases à cocher devant les morceaux modifiés.

Enfin, la plupart des interfaces graphiques ont des fonctions pratiques, comme le paramétrage de l’affichage par défaut de telle ou telle partie de l’interface, les recherches locales, une bonne interface de résolution de conflit en cas de rebase ou merge, etc. qui simplifient la vie quotidienne du développeur.

La GUI pour comprendre les opérations sur les commits

Un autre avantage d’une interface graphique – et en particulier d’avoir une vue claire de l’arbre des commits – c’est qu’elle permet de simplifier la compréhension de certaines opérations, en particulier les manipulations de cet arbre telles que merge, rebase, squash

J’insiste sur la vue claire de l’arbre des commits : la CLI permet une visualisation de cet arbre, mais l’affichage par défaut est chiche en informations :

$ git log --graph

Une version plus complète de la commande permet d’avoir un affichage plus complet et compact :

git log --all --decorate --oneline --graph

Mais force est de constater qu’un affichage graphique du même arbre semble plus lisible et complet :

Mon expérience, partagée par beaucoup de développeurs que j’ai vu apprendre Git, est que ce type d’interface est nécessaire pour une bonne compréhension et un usage efficace de ces opérations, en particulier de rebase.

C’est d’autant plus vrai que la doc officielle de Git est à la fois très dense (elle veut couvrir beaucoup de cas) et, pour la version française, utilise des choix de traduction parfois étonnants qui obligent à apprendre tout le vocabulaire en double (la version anglaise utilisée dans la vie de tous les jours et dans les commandes ; et la version française utilisée dans la documentation).

Mon expérience, c’est que si cette documentation a beaucoup de qualités – en particulier sa complétude est très appréciable quand on connait déjà Git et que l’on cherche un comportement particulier – mais est assez mal adaptée à une formation initiale à l’outil.

La CLI ne permet pas de « comprendre Git »

Ici je réponds à un argument que j’ai souvent lu, et qui est :

Même si on ne l’utilise pas, il faut au moins apprendre à utiliser la CLI de Git, parce que c’est indispensable pour comprendre ce que fait Git et que les interfaces graphiques font de la magie en lançant toutes seules des commandes compliquées.

Pour moi, ce type d’argument est faux, et pour plusieurs raisons indépendantes.

Bien utiliser un outil c’est d’abord en comprendre les règles fonctionnelles

Git est un outil puissant, mais compliqué, parce qu’il permet énormément de choses.

Ce que j’ai constaté au travers des formations et des moult questions que j’ai vu passer sur diverses plateformes, c’est que généralement :

C’est la compréhension fonctionnelle qui pose problème : indépendamment de l’outil, l’utilisateur ne sait pas quelles opérations fonctionnelles effectuer pour résoudre son problème.

Ce n’est pas l’utilisation de la CLI, pas plus que d’une quelconque GUI, qui va permettre à l’utilisateur de mieux appréhender Git. Ce dont il a besoin généralement, c’est de savoir ce que peut faire Git pour l’aider, et comment.

Par exemple, s’il a une branche de développement pas à jour, que va-t-il devoir faire ? Un rebase, un merge, une nouvelle branche et cherry-pick certains de ses commits, etc. ? Est-ce que l’utilisateur a la connaissance de toutes ces possibilités et de leurs cas d’utilisation ? Généralement, non.

Le mythe du problème des commandes magiques faites par les GUI

Un autre argument qui revient souvent, c’est que les interfaces graphiques utiliseraient des commandes compliquées « sous le capot », que l’on ne maitriserait donc pas, ce qui :

  1. serait dangereux,
  2. empêcherait de comprendre ce qui est vraiment fait.

Ce à quoi je réponds :

  1. On utilise un outil précisément pour faire de façon simple ce qui est compliqué sans lui.
  2. Si on trouve qu’un outil est dangereux, soit c’est vraiment le cas (et il faut le prouver et changer d’outil ou le corriger), soit c’est de la méfiance à priori et n’a pas de sens.
  3. Les GUI ne sont pas magiques : ce qu’elles font est, d’une façon ou d’une autre, permit pas Git.
  4. Vous croyez vraiment qu’un utilisateur débutant comprend mieux ce que fait une commande de 50 caractères avec 4 options que ce que fait un appui sur un bouton ?

« Utiliser la CLI » ≠ « Utiliser des commandes de bas niveau ou natives »

Nous ne sommes plus à l’époque de Git < 1.5

Historiquement et surtout avant la version 1.5, les commandes Git étaient très centrées sur le système de fichier et imposaient en effet de comprendre assez bien ce que Git réalisait pour pouvoir être utilisées. En fait, Git était plus proche d’une boite à outils que d’un système de gestion de contenu à proprement parler.

Ça n’est plus le cas depuis, parce que depuis Git a intégré un nouveau jeu de commandes.

Peut-être que vous avez dû apprendre des commandes absconses, ça n’est plus nécessaire aujourd’hui.

Plomberie et porcelaine

Les commandes proches du système de fichier existent toujours et sont pratiques pour une intégration dans des programmes ou dans des scripts. On les appelle les commandes de plomberie (« plumbing » en anglais) et ne devraient pas être tapées à la main dans un terminal (dixit la doc officielle sur le sujet).

Mais il existe aussi tout un tas de commandes dont l’ergonomie a été pensée pour des utilisateurs humains. On les appelle les commandes de porcelaine et vous savez quoi ? Elles sont aussi éloignées du fonctionnement interne de Git que peut l’être un appui sur un bouton dans une interface graphique.

Et c’est normal, puisque dans les deux cas ce sont des commandes destinées à être utilisées par des humains, et donc sont censé êtres simples, et non refléter au plus près ce qui est fait au niveau du système de fichiers.

Mais…

… l’utilisation au clavier…

Toute bonne interface graphique peut être entièrement pilotée au clavier, et ne vous obligera pas à « perdre du temps » à le lâcher pour utiliser la souris.

… ça va plus vite…

Taper raccourci clavier n’est pas plus lent que de taper une commande de plusieurs caractères. Même lâcher son clavier et utiliser la souris est sans doute plus rapide.

Apprendre les raccourcis clavier du logiciel utilisé n’est pas plus long ni plus compliqué que d’apprendre les commandes Git, ni que de paramétrer des alias personnalisés d’ailleurs.

… et c’est plus accessible.

L’accessibilité est probablement la meilleure raison de préférer la CLI à une interface graphique.

Quel client graphique ?

À cette étape le lecteur avisé demandera :

D’accord, mais quel client graphique Git me recommandes-tu ?

Eh bien… c’est une bonne question.

Le problème est que de toute évidence, créer un bon client graphique Git, avec une bonne ergonomie, semble être quelque chose de complexe. Beaucoup de clients Git libres sont moches et/ou d’une ergonomie douteuse, et beaucoup de bons clients Git sont propriétaires. Cela dit, il semble y avoir plus de clients Git libres maintenant qu’à l’époque où j’ai fait le tour des principaux clients existants.

Ajoutez à ça que ça fait longtemps que je n’utilise plus que celui intégré à mon IDE, et donc que je ne sais pas ce que vaut le marché actuel.

Si le sujet vous intéresse, Git maintient une liste sur son propre site.

Néanmoins, voici quelques avis personnels de clients que j’ai testés personnellement, n’hésitez pas à compléter avec vos retours en commentaires !

Clients libres

Clients propriétaires

  • SmartGit : si vous n’avez rien contre les interfaces un peu spartiates, c’est pour moi le meilleur client indépendant, en particulier grâce à un excellent outil de diff/merge. Gratuit pour une utilisation non commerciale.
  • Sourcetree : a été un bon client gratuit pour Windows et Mac, mais souffre de choix de développement hasardeux, comme la non-intégration d’outil de diff/merge, ou la suppression sauvage de certaines options (le force-push n’a été possible qu’en CLI pendant plusieurs mois à une époque, alors qu’il avait fonctionné avant…)
  • GitKraken : la bêta était prometteuse, mais le modèle économique (version gratuite qui ne permet l’accès qu’aux dépôts publics des plus grands fournisseurs) me semble pas très sain.
  • … plein d’autres que je n’ai jamais testés.

Aider et demander de l’aide sur Git

J’ai besoin d’aide

Indiquez directement le client que vous utilisez, et sachez vous servir de sa documentation.

C’est normal d’avoir des difficultés à comprendre les concepts Git et à en connaitre toutes les possibilités.

Mais c’est à vous de savoir comment transcrire une indication fonctionnelle précise en actions dans votre client particulier.

Je réponds à une demande d’aide

Ne partez pas du principe que « Git = CLI ». En particulier :

Ne donnez jamais de lignes de commande à taper, encore moins sans les explications associées.
Une ligne de commande n’est jamais une explication en soi. Même si elle fonctionne.

Le but est que la personne en face sache ce qu’elle doit faire fonctionnellement pour résoudre son problème, de façon à ce qu’elle ne reparte ni avec une ligne de commande magique, ni avec l’impression que Git c’est encore l’un de ces « putain d’outils de libriste de merde qui ne s’utilisent qu’en ligne de commande et ne sont utilisables que par des barbus asociaux » (critique hélas trop fréquente, même si pas forcément verbalisée en ces termes).


La CLI est une interface de pilotage de Git qui peut vous convenir, et qui a ses avantages – en particulier celui d’être toujours disponible si Git est installé.

Ça n’en fait pas une interface universellement pratique, en particulier elle est plutôt génératrice d’erreurs et de temps perdu. Elle est aussi assez peu pratique pour l’apprentissage de Git, spécialement des concepts avancés de manipulation de l’arbre des commits.

Au contraire, les interfaces graphiques, en présentant sensiblement plus d’informations simultanées, permettent d’éviter des erreurs et de mieux appréhender des concepts complexes. À ce propos, il n’y a pas besoin que l’interface soit réellement graphique, on pourrait imaginer qu’une interface en ncurses fasse très bien le job.

Donc, utilisez la CLI si c’est le meilleur outil pour vous. Mais ne partez jamais du principe que c’est la meilleure interface pour les autres, et surtout, arrêtez de répondre aux demandes d’aide en donnant des commandes Git CLI sans explications. Parce qu’une ligne de commande n’est en aucun cas une explication en soi.


Le logo Git est CC BY 3.0 Jason Long.

30 commentaires

N’hésitez pas à donner votre avis ici, tant qu’il est construit et productif :)

Amis validateurs, j’ai hésité à faire de ce billet un article. Si vous voulez le passer en article, je ferai une passe de relecture un peu plus sérieuse que la vague relecture en diagonale que j’ai eu le courage de faire…

J’avoue que j’utilisais pas mal la GUI au début, pour comprendre les bases sans trop prendre de risque (généralement les GUI demandent de valider avant de faire quelque chose, du coup on peut évaluer l’impact avant de tout casser). C’est une super approche pour ceux qui maîtrisent pas trop l’outil et veulent mettre un pied dans le bain sans risque la noyade.

Depuis quelques années je suis pas mal passé en CLI (surtout depuis que je fais un peu de devops comme disent les hipsters), mais avec VSCode je me retrouve à faire une bonne partie des actions courantes (add/commit/push) via la GUI de VSCode, surtout si j’ai beaucoup de modifs en même temps (éventuellement pour diviser en plusieurs commits, ça aide bien).

Au final y’a pas vraiment de meilleur outil, juste des questions de préférence, de capacité, ou tout simplement de motivation.

Le plus important reste le workflow derrière, sur la façon d’organiser ses branches, de rebase quand on pull le remote, de séparer les features, etc.


Une petite note quand même : quand on chercher à faire quelque chose de précis sur Git on trouvera plus facilement une ligne de commande à exécuter qu’un process à suivre dans une GUI, d’autant plus que la CLI est universelle. C’est à savoir quand on tombe dans des cas un peu borderline, même si 98% du temps la GUI suffira.

Au final y’a pas vraiment de meilleur outil, juste des questions de préférence, de capacité, ou tout simplement de motivation.

Le plus important reste le workflow derrière, sur la façon d’organiser ses branches, de rebase quand on pull le remote, de séparer les features, etc.

viki53

Je suis plutôt d’accord. En vrai ce que je reproche surtout à tous ces « sachants » qui « aident » sur Internet, c’est de considérer que la CLI est meilleure, voire la seule option possible.

surtout depuis que je fais un peu de devops comme disent les hipsters

viki53

Un point qui m’intéresse, quel rapport fais-tu entre le devops et l’utilisation de Git en CLI ? Tu te retrouves à beaucoup utiliser Git sur des serveurs ?

Au final y’a pas vraiment de meilleur outil, juste des questions de préférence, de capacité, ou tout simplement de motivation.

Le plus important reste le workflow derrière, sur la façon d’organiser ses branches, de rebase quand on pull le remote, de séparer les features, etc.

viki53

Je suis plutôt d’accord. En vrai ce que je reproche surtout à tous ces « sachants » qui « aident » sur Internet, c’est de considérer que la CLI est meilleure, voire la seule option possible.

Y’a pas mal d’élitistes de la CLI, effectivement. Après comme je l’ai dit dans mon ajout, y’a aussi que la CLI a l’avantage d’être universelle là où les GUI ont chacune leur approche. Du coup ça crée un clivage rapidement, surtout quand il s’agit de documenter (la documentation officielle étant basée sur la CLI)…

surtout depuis que je fais un peu de devops comme disent les hipsters

viki53

Un point qui m’intéresse, quel rapport fais-tu entre le devops et l’utilisation de Git en CLI ? Tu te retrouves à beaucoup utiliser Git sur des serveurs ?

SpaceFox

Sur les serveurs directement pas vraiment, j’évite même de donner des accès Git aux serveurs de production, je passe par des pipelines de build qui vont récupérer les sources puis pousser sur les serveurs une fois les étapes de build réalisées.

Pour l’aspect CLI je pense surtout à des aspect de gestion de repo ou de maintenance.

Récemment j’ai par exemple du séparer une repo en deux (front et back), en gardant l’historique nettoyée de chaque partie dans les nouveaux repos. Typiquement un truc pas forcément prévu par les GUI… donc passage par la CLI.

Pareil quand il s’agit d’éditer un commit déjà fait, j’ai des alias pour le git commit --amend --no-edit et git push --force-with-lease qui font que je peux écraser même si j’ai déjà poussé (tant que personne d’autre n’a écrit entre temps) l’esprit tranquille. Toutes les options ne sont pas forcément gérées par les GUI, c’est un peu le reproche que je leurs fais (même si encore une fois, pour 95% des gens ou plus ça ne posera pas de problème).

Billet très intéressant. J’ai jamais passé le cap de "chercher une GUI qui me convienne et apprendre à m’en servir", du coup j’imagine que je suis toujours rester utilisateur de la commande par défaut.

Ce que je trouve intéressant c’est que git c’est un logiciel que beaucoup de développeurs utilisent tous les jours et que très peu de gens savent vraiment bien s’en servir (de manière complète). Je suis a chaque fois étonné de remarquer que git est vraiment un logiciel dur d’apprentissage quand on veut dépasser clone/commit/push.

Quelle est la branche courante.

Ca c’est un truc que j’ai jamais compris. Dans git il n’existe pas à ma connaissance un moyen immédiat et qui ne fait que ça, de savoir sur quelle branche on est. git status le dit, et on peut aussi faire git branch pour voir sur quelle branche on se trouve, mais rien de direct et simple.

Super billet @SpaceFox !

Je te rejoins entièrement sur tous tes arguments.

Pour ma part je viens de Bazaar, un gestionnaire de version décentralisé lui aussi, mais dont la particularité était d’être conçu pour être utilisé efficacement dans sa version GUI. Lorsqu’il a malheureusement été voué à l’abandon, je me suis alors tourné vers Git, seul concurrent sérieux en 2015. Et là je me suis rué sur smartgit, malgré ma détestation bien connue du Java, parce qu’il est aussi le seul client portable multiplateforme.

Aujourd’hui j’utilise un peu plus la ligne de commande au boulot par obligation, mais je regrette toujours autant le manque absolu d’ergonomie et la complexité de Git.

Un bon client de diff est intégré à VSCode, donc heureusement je peux au moins faire ma review avant commit dans une interface adaptée à du code (nom d’un chien qui s’est dit que la coloration syntaxique était en option dans un lecteur de diff ??? Et je ne vous parle pas de la CLI).

Git est un outil intéressant, mais clairement pas le meilleur qu’on pourrait imaginer, et l’écosystème est triste à pleurer quand aux outils graphiques.

Git pourrait avoir beaucoup d’usages à destination d’utilisateurs non informaticiens, malheureusement c’est très compliqué sans une surcouche GUI fait maison adaptée sur mesure au besoin…

+1 -0

Ca c’est un truc que j’ai jamais compris. Dans git il n’existe pas à ma connaissance un moyen immédiat et qui ne fait que ça, de savoir sur quelle branche on est. git status le dit, et on peut aussi faire git branch pour voir sur quelle branche on se trouve, mais rien de direct et simple.

Anto59290

git branch --show-current En soi, on a rarement besoin du nom seul de la branche cela dit.

Je suis par ailleurs pas complètement d’accord avec l’argument que la CLI oblige à connaitre

La syntaxe exacte de la commande qui permet d’y arriver.

et qu’elle ne permet pas d’explorer les possibilités comme une interface graphique. L’auto-complétion sous les shells dignes de ce nom est plutôt performante et offre des aides utiles. La courbe d’apprentissage est plus raide qu’avec une interface graphique, c’est indéniable, mais à mon avis sur un outil qu’on utilise tous les jours, c’est pas un argument valable.

Au final, la préférence CLI/GUI est purement personnelle, et les arguments avancés sont subjectifs (ce qui ne veut pas dire qu’ils ne sont pas intéressants! :) ). À part l’argument de l’accessibilité peut être, mais ça je m’y connais pas assez pour juger.

EDIT : d’ailleurs j’y pense parce que je viens juste d’avoir le cas, un avantage énorme à savoir au moins se dépatouiller avec la CLI, c’est son uniformité. Peu importe l’OS sur lequel tu es, si la machine à un serveur graphique ou pas, la CLI est la même (par contre le confort du shell… :-°). Et ça, c’est précieux quand on aide un autre utilisateur à distance. Je viens juste de dépanner une collègue en 5 minutes en lui envoyant trois commandes par texto. J’aurai été parfaitement incapable de faire ça sur une GUI (oui euh le bouton forme de flèche, non pas celui-là, l’autre à droite), d’une part parce que je m’en sers pas, mais surtout parce que même si j’en utilisais une, il y aurait fort à parier que ce serait pas la même que mes collègues.

+3 -0

Article intéressant :D

Je vois qu’on est d’accord sur le fait que la gestion de git des IDEs de JetBrains est tous simplement magnifique. Et leurs outils de diff/gestion de conflit… magique !

Je garde un Inettlij sous la main sur ma machine juste pour pouvoir faire des manipulations git via une GUI.

En revanche, IntelliJ Idea Community Edition est open-source, de ce fait, peut-con considéré que leurs systèmes de gestion de git est propriétaire ?

J’ai également testé Gitkraken (en fait, je l’utilise de temps en temps depuis la toute première release officielle). L’interface pour visualiser l’arbre des commis est jolie (c’est mon point de vue), mais le reste est dans la moyenne des autres outils… Le pire, c’est les fuites mémoires qu’il a. Il m’ai arrivé qu’il ce retrouve à utiliser 14Go de ram… alors quand on a un projet versionné à moins de 10k de code et moins de 1k commits, il y a un pépin :rofl: (Le revers de la médaille d’Electron).

L’utilisation du CLI ou GUI, et ce en dehors de Git, est un éternel débat. Par exemple, pour installer un programme, rien de mieux qu’un bon "apt install leprog" non ? Eh bien certains préféreront passer par une interface graphique, même si cela prend plus de temps. D’un autre coté, on n’installe pas un programme toutes les 5 minutes, donc le temps passé peut être relatif.

Pour mon utilisation de Git, j’utilise 3 programmes.

Ligne de commande

Pour tout ce qui est commit/rebase/changement de branch, tout ce qui manipule le dépôt.

IDE Eclipse

J’utilise l’IDE Eclipse pour le dev et c’est par l’IDE que je visualise les diff. C’est pratique car on visualise tous les fichiers modifiés et quand on clique sur un fichier, cela ouvre le nouveau et l’ancien fichier et on voit les différences entre les deux. Le coté pratique, c’est qu’on peut modifier les fichiers en mode diff, pas besoin de l’ouvrir à coté pour faire des petites corrections.

Gitg

Gitg permet de visualiser le dépôt avec l’historique des commit et les branches dans une interface graphique. Il permet de voir les fichiers modifiés pour chaque commit et d’autre chose.

Pour conclure, je ne pense pas qu’il y ait une seule bonne façon de faire, chacun doit trouver les outils qui correspondent à ses besoins. Il ne faut pas forcément se centraliser sur UN outil.

+0 -0

Très bon article.

Et bien qu’utilisant principalement la CLI, j’apprécie en effet la simplicité de certaines actions en GUI pour ça j’utilise gitg du project gnome. GUI simpliste mais très pratique pour :

  • afficher l’abre des commit
  • lister les branches
  • choisir les lignes de modifications pour un commit
  • amender un commit

C’est cette interface que je propose aux nouveaux arrivants à git et non informaticiens pour éviter de les perdre.

git branch --show-current En soi, on a rarement besoin du nom seul de la branche cela dit.

Source: adri1

C’est drôle ça. Ça ne marche pas chez moi car ma version de Git n’est pas assez récente (je suis sur une Ubuntu LTS). Ca a été ajouté "récemment": cf ce commit : https://github.com/git/git/commit/0ecb1fc7269e15be890870937b8b639c987abd08

Personnellement je veut savoir le nom (et uniquement le nom) de la branche courante entre 5 et 10 fois par jour je dirais. Par exemple tu reviens d’une pause repas et tu veux être sur d’être sur la bonne branche. Tu as fait un rebase / vérifié un truc sur une autre branche et tu veux vérifier la branche courante. Ou alors quand je veut créer une nouvelle branche je m’assure de bien partir de master. J’imagine qu’on a tous un peu des usages différents de git, mais pour moi c’est une opération assez courante.

Personnellement je veut savoir le nom (et uniquement le nom) de la branche courante entre 5 et 10 fois par jour je dirais. Par exemple tu reviens d’une pause repas et tu veux être sur d’être sur la bonne branche. Tu as fait un rebase / vérifié un truc sur une autre branche et tu veux vérifier la branche courante. Ou alors quand je veut créer une nouvelle branche je m’assure de bien partir de master. J’imagine qu’on a tous un peu des usages différents de git, mais pour moi c’est une opération assez courante.

Anto59290

@Anto59290 C’est le genre de truc qui est intégré de base à oh-my-zsh et auquel on ne pense plus une fois mis en place : le nom de la branche courante est affiché directement en début de ligne dans le terminal.

Sinon tu peux te créer un alias, par exemple alias gitcb='git branch --show-current' (à mettre dans ton rc si tu veux le rendre permanent), et tu n’auras plus qu’à taper gitcb pour avoir l’info.

C’est un des avantages de le CLI : on peut customiser pas mal de choses suivant ses besoins et créer des raccourcis facilement.

git branch --show-current En soi, on a rarement besoin du nom seul de la branche cela dit.

adri1

Si je me réfère à la réponse de @Anto59290 juste au-dessus, la commande est effectivement récente. Je ne l’ai pas dans la version 2.20.1 de Git qui est dans Ubuntu 19.10 (reste à savoir pourquoi Ubuntu d’octobre 2019 embarque une version de Git publiée en décembre 2018).

C’est un exemple qui montre que la CLI n’est pas si universelle que ça, mais c’est du pinaillaige. Ce qui m’étonne plus, c’est l’argument qui dit qu’on a rarement besoin du nom de la branche courante : c’est un truc dont je me sers tout le temps, à commencer pour vérifier que je ne commite pas dans la mauvaise branche – et ça m’a évité pas mal d’erreurs. J’imagine ne pas être le seul à avoir ce besoin, puisque c’est presque la seule info qu’affiche un outil comme oh-my-zsh.

Je suis par ailleurs pas complètement d’accord avec l’argument que la CLI oblige à connaitre

La syntaxe exacte de la commande qui permet d’y arriver.

et qu’elle ne permet pas d’explorer les possibilités comme une interface graphique. L’auto-complétion sous les shells dignes de ce nom est plutôt performante et offre des aides utiles. La courbe d’apprentissage est plus raide qu’avec une interface graphique, c’est indéniable, mais à mon avis sur un outil qu’on utilise tous les jours, c’est pas un argument valable.

adri1

Je viens d’essayer, l’auto-complétion sous bash est assez pitoyable. Celle sous zsh est bien plus complète, mais du coup ça n’est pas « la CLI de Git », c’est « la CLI de Git + zsh », ce qui est bien moins universel ; d’autant que zsh n’est généralement installé que chez des gens qui utilisent déjà massivement les outils en CLI.

D’autre part, avoir une courbe d’apprentissage raisonnablement pas trop raide aide beaucoup à faire accepter l’outil (qui n’est pas toujours choisi, rappelons-le) et donc à ce que les utilisateurs cherchent d’eux-même à l’utiliser correctement et de façon avancée.

Au final, la préférence CLI/GUI est purement personnelle, et les arguments avancés sont subjectifs (ce qui ne veut pas dire qu’ils ne sont pas intéressants! :) ). À part l’argument de l’accessibilité peut être, mais ça je m’y connais pas assez pour juger.

adri1

Je reste persuadé que :

  • L’apprentissage des fonctions de modifications de l’arbre de commit
  • Le commit partiel (= prendre seulement une partie des modifications à l’intérieur d’un fichier)

sont d’expérience et objectivement plus simples en GUI qu’en CLI, au-delà de toute préférence personnelle.

EDIT : d’ailleurs j’y pense parce que je viens juste d’avoir le cas, un avantage énorme à savoir au moins se dépatouiller avec la CLI, c’est son uniformité. Peu importe l’OS sur lequel tu es, si la machine à un serveur graphique ou pas, la CLI est la même (par contre le confort du shell… :-°). Et ça, c’est précieux quand on aide un autre utilisateur à distance. Je viens juste de dépanner une collègue en 5 minutes en lui envoyant trois commandes par texto. J’aurai été parfaitement incapable de faire ça sur une GUI (oui euh le bouton forme de flèche, non pas celui-là, l’autre à droite), d’une part parce que je m’en sers pas, mais surtout parce que même si j’en utilisais une, il y aurait fort à parier que ce serait pas la même que mes collègues.

adri1

L’argument est classique. Je l’ai expliqué dans le billet et le je répète ici : pour moi, dépanner quelqu’un sur Git en lui envoyant des commandes, c’est une erreur et ne devrait pas être fait, à l’exception de deux cas :

  1. C’est vraiment urgent de passer ces commandes et on a pas le temps de s’assurer que la personne que les exécute comprenne vraiment ce qu’elle fait et apprenne à utiliser son client.
  2. La personne qui a un problème utilise déjà la CLI, comprends fonctionnellement ce qu’elle veut faire mais a un problème avec la syntaxe.

Si tu es hors de ces cas, tu n’aides pas la personne : tu fais le travail à sa place, de ta manière, sans respecter sa façon de faire. Ça ne l’aide ni à comprendre Git, ni à se débrouiller elle-même dans le futur : au mieux elle va copier la commande donnée quand elle aura un problème, et si ce n’est pas exactement le même ça va échouer.

C’est exactement le même procédé que donner un bout de code tout fait à un quidam qui vient poser une question sur un forum : ça va le débloquer mais pas l’aider, parce qu’il aura copié un truc sans comprendre. D’ailleurs, il me semble que c’est un truc qu’on apprécie assez peu sur ZdS (même si le cas est rare).

La bonne réaction à avoir quand quelqu’un te demande de l’aide sur Git, hors des deux cas sus-cités, c’est de s’assurer que cette personne ait bien compris ce qu’elle devait faire fonctionnellement. Une fois qu’elle a compris ça, charge à elle de se documenter sur comment le faire avec son client particulier ; ainsi elle aura compris ce qu’elle doit faire, appris comment le faire et saura s’adapter aux situations futures.

Évidemment, ça dépend d’avoir un peu plus de temps, d’être ferme sur la partie « regarde la doc de ton outil maintenant que tu sais ce que tu dois faire » et c’est plus compliqué que juste balancer une ligne de commande en demandant à l’autre de se démerder avec.

À la limite, si c’est toi en tant qu’aidant qui n’a pas le temps de faire une réponse propre, une variante de RTFM sera mieux pour tout le monde. Testé et approuvé.

PS : note qu’ici le problème n’est pas « utiliser la CLI pour répondre à la question » mais bien « faire le travail au lieu d’aider ». Si par exemple sur une GUI tu prends la main à distance sur l’ordi du collègue pour cliquer aux bons endroits à sa place, le principe et le résultats sont le même : ça peut être rapide et confortable pour l’aidant, l’aidé a son problème résolu… mais ne sait absolument pas pourquoi ni comment le refaire (autrement que par copie de code / clics magiques) la fois suivante.

(@adri1 je cite ton message parce que tu es le premier à avoir sorti les arguments auxquels je réponds, mais rien de personnel hein)

C’est un exemple qui montre que la CLI n’est pas si universelle que ça, mais c’est du pinaillaige. Ce qui m’étonne plus, c’est l’argument qui dit qu’on a rarement besoin du nom de la branche courante : c’est un truc dont je me sers tout le temps, à commencer pour vérifier que je ne commite pas dans la mauvaise branche – et ça m’a évité pas mal d’erreurs. J’imagine ne pas être le seul à avoir ce besoin, puisque c’est presque la seule info qu’affiche un outil comme oh-my-zsh.

SpaceFox

Il a dit le nom « seul » et c’est je pense ce qui fait toute la différence. Le nom de la branche courante est déjà visible lors d’un git branch : on voit les branches locales listées et la courante (si on est sûr une branche) est précédée d’un signe *.

Avoir le nom seul c’est uniquement utile pour certains scripts (afficher le nom de la branche dans le prompt du terminal, construire un paquet en y intégrant le nom de la branche, etc.), et ce sont des opérations où il est peu courant d’avoir à taper manuellement la commande pour récupérer le nom de branche (git branch --show-current, git rev-parse --abbrev-ref HEAD ou autres).

Personnellement je veut savoir le nom (et uniquement le nom) de la branche courante entre 5 et 10 fois par jour je dirais. Par exemple tu reviens d’une pause repas et tu veux être sur d’être sur la bonne branche. Tu as fait un rebase / vérifié un truc sur une autre branche et tu veux vérifier la branche courante. Ou alors quand je veut créer une nouvelle branche je m’assure de bien partir de master. J’imagine qu’on a tous un peu des usages différents de git, mais pour moi c’est une opération assez courante.

Anto59290

En quoi est-il gênant pour ces opérations d’avoir autre chose que le nom de la branche courante qui s’affiche en complément ?

Le git status est d’ailleurs bien utile, puisqu’en plus du nom de branche il nous assure que le dépôt local est bien dans l’état que l’on veut.

En quoi est-il gênant pour ces opérations d’avoir autre chose que le nom de la branche courante qui s’affiche en complément ?

C’est une question de charge cognitive pour moi. Je vais mettre plus de temps a voir la branche / comprendre. Au plus il y a d’info inutiles au plus on met du temps à réagir, non ?

Si je fait un git branch ou un git status je vais probablement avoir 10 ou 15 lignes au minimum qui vont s’afficher sur mon terminal. Ce supplément d’info va me ralentir pour trouver la seule info qui m’intéresse : ma branche courante. En soit je peux vivre avec (ou utiliser un alias) mais je trouve bizarre qu’il n’y ai pas de commande immédiate pour faire ça. En gros dans la manière dont j’utilise git, savoir sur quelle branche je suis c’est un truc a vérifier avant certaines opérations, d’où le fait que je m’en serve souvent.

C’est une question d’ergonomie aussi. Avec la version de Git que j’ai (2.20.1) :

  • git branch ne m’affiche pas la liste des branches : elle m’envoie dans une interface genre less ou man dont il faut que je sorte explicitement avec q. Par contre la branche courante a une étoile et est coloriée en vert, c’est difficile de la rater.
  • git status m’affiche d’abord ma branche (facile à repérer) puis toutes mes modifications en cours ; pour peu que j’en ai quelques-unes (en fonction de la taille du terminal) l’information « branche courante » va se retrouver hors de l’écran.

Tout ça reste du détail de toutes façons, ça dépend beaucoup du workflow utilisé, et le fait d’avoir la branche courante affichée en permanence dans un coin n’est qu’un avantage mineur d’une GUI.

Merci pour cette tribune @SpaceFox. :)

Je me rappelle avoir eu des échanges avec toi sur twitter à propos de cette histoire d’utiliser git en cli/gui et j’étais effectivement de ceux qui étaient des fervents défenseurs de leur utilisation en cli, notamment pour les arguments que tu as cités et démontés.

Aujourd’hui je me rends compte que les personnes ont leur manière bien à elles de travailler et en ce qui me concerne j’en reste toujours à une utilisation en ligne de commande pour des raisons qui, si elles ne sont pas universelles, reflètent mon état d’esprit personnel :

  • exécuter chaque commande par acquit de conscience et savoir pourquoi on le fait ;
  • rester familier avec la ligne de commande, ce que je trouve indispensable en tant que personne spécialiste de l’informatique ;
  • essayer de rester dans une mentalité Keep It Simple Stupid (KISS).

Maintenant, je te concède que j’utilise de plus en plus des outils graphiques pour résoudre certaines opérations un peu casse-bonbon, genre des conflits lors de merge/rebase et seulement à l’aide de mon IDE.

Si certaines personnes ont un intérêt à utiliser une GUI pour travailler, c’est très bien. Je pense notamment à des personnes qui ne sont pas développeuses mais qui ont besoin d’apporter des changements simples, au sein d’un dépôt (ce qui se limite à faire des commits, par exemple).

Pour le reste, mes raisons personnelles de ne pas utiliser de GUI :

  • trop de choix qui laissent un sentiment d’indécision / de frustration (alors que la CLI met tout le monde d’accord) ;
  • tu l’as dit toi-même : « OK, c’est un peu chargé ». Je n’ai pas besoin d’avoir des informations que je ne souhaite pas et désire m’en tenir au strict nécessaire ;
  • je me sentirais franchement perdu à faire des opérations pointues sur une GUI alors qu’avec la CLI il y a une documentation de référence, des étapes bien documentées et, pour peu qu’on ait un minimum de recul, on s’en sort. Et encore je me considère débutant dans son utilisation.

Je pense qu’au final la fin de ton billet résume assez bien le débat :

Donc, utilisez la CLI si c’est le meilleur outil pour vous. Mais ne partez jamais du principe que c’est la meilleure interface pour les autres, et surtout, arrêtez de répondre aux demandes d’aide en donnant des commandes Git CLI sans explications. Parce qu’une ligne de commande n’est en aucun cas une explication en soi.

À bientôt.

J’étais aussi un grand adepte de la ligne de commande. Et c’est en commençant à utiliser une GUI que j’ai vraiment commencé à maîtriser GIT. La UI apporte une visibilité. On sait ou on se trouve, ou se trouve notre branche par rapport aux autres, on voit de suite si on a besoin de rebase etc… Je paye ma licence GitKraken et franchement 40€/an pour un soft que j’utilise absolument tous les jours je ne regrette pas et je le recommande.

Ce qui m’étonne plus, c’est l’argument qui dit qu’on a rarement besoin du nom de la branche courante : c’est un truc dont je me sers tout le temps, à commencer pour vérifier que je ne commite pas dans la mauvaise branche – et ça m’a évité pas mal d’erreurs. J’imagine ne pas être le seul à avoir ce besoin, puisque c’est presque la seule info qu’affiche un outil comme oh-my-zsh.

Comme le dit @entwanne, c’est bien le nom de la branche seul dont je parle. Savoir sur quelle branche on est est bien sur important, sauf que cette information seule est rarement utile. Ce qui est intéressant, c’est aussi de connaitre son état par rapport aux branches distantes, et l’état du répertoire de travail. Perso dans mon prompt, je mets des indicateurs sur l’état du staging area et du working directory en plus de la branche, sinon je me retrouve à faire des git status en permanence.

Je trouve par ailleurs qu’il est un peu ironique de reprocher à Git de ne pas offrir une façon très simple d’afficher que la branche courante mais de présenter comme un point fort le fait que la GUI te bombarde de plein d’informations qui remplissent visiblement un moniteur en 1080p. Je plussoie d’ailleurs fortement le commentaire de @Ge0 sur ce point

  • tu l’as dit toi-même : « OK, c’est un peu chargé ». Je n’ai pas besoin d’avoir des informations que je ne souhaite pas et désire m’en tenir au strict nécessaire ;
  • je me sentirais franchement perdu à faire des opérations pointues sur une GUI alors qu’avec la CLI il y a une documentation de référence, des étapes bien documentées et, pour peu qu’on ait un minimum de recul, on s’en sort. Et encore je me considère débutant dans son utilisation.
Ge0

Quand je vois ta capture d’écran, je sais pas où donner de la tête. De la même façon qu’on peut être perdu face à une interface légère quand on sait pas trop ce qu’on veut faire, on peut être perdu face à une interface chargée quand on sait précisément ce qu’on souhaite faire. C’est une des raisons principales pour lesquelles je préfère souvent les outils CLI aux GUI, je suis paumé quand mon écran est rempli de boutons et de sous fenêtres dans tous les sens. C’est un peu étrange quand j’y pense d’ailleurs, parce que d’un autre côté, avec une fenêtre remplie de terminaux avec du texte dans tous les sens, c’est tout aussi voire plus dense en information, mais ça me dérange pas du tout.

Je viens d’essayer, l’auto-complétion sous bash est assez pitoyable. Celle sous zsh est bien plus complète, mais du coup ça n’est pas « la CLI de Git », c’est « la CLI de Git + zsh », ce qui est bien moins universel ; d’autant que zsh n’est généralement installé que chez des gens qui utilisent déjà massivement les outils en CLI.

Clairement, bash est inutilisable (en général je veux dire, pas qu’avec Git). Sa popularité me laisse toujours perplexe. Juger de la CLI de git avec bash, c’est comme juger de la GUI de git sur un client codé avec les pieds par quelqu’un qui n’a aucune notion en design UI et UX. J’ai pas d’exemple en tête comme je connais pas du tout l’offre, mais ça doit exister.

D’autre part, avoir une courbe d’apprentissage raisonnablement pas trop raide aide beaucoup à faire accepter l’outil (qui n’est pas toujours choisi, rappelons-le) et donc à ce que les utilisateurs cherchent d’eux-même à l’utiliser correctement et de façon avancée.

Je sais pas, perso je préfère un outil qui me dit franchement "si tu veux m’utiliser correctement, faudra investir du temps" à un outil qui cache un peu trop ses subtilités et veut paraitre simple alors qu’il ne l’est pas. Peu importe l’interface dont on se sert, Git est un outil complexe qui nécessite un investissement pour s’en servir proprement en comprenant ce qu’on fait un minimum.

Au final, la préférence CLI/GUI est purement personnelle, et les arguments avancés sont subjectifs (ce qui ne veut pas dire qu’ils ne sont pas intéressants! :) ). À part l’argument de l’accessibilité peut être, mais ça je m’y connais pas assez pour juger.

adri1

Je reste persuadé que :

  • L’apprentissage des fonctions de modifications de l’arbre de commit
  • Le commit partiel (= prendre seulement une partie des modifications à l’intérieur d’un fichier)

sont d’expérience et objectivement plus simples en GUI qu’en CLI, au-delà de toute préférence personnelle.

Meh, j’ai l’impression que dans les deux cas, les difficultés seront conceptuelles. Il faut comprendre qu’un dépôt Git est un arbre orienté de commits et que tout le reste, c’est s’amuser avec cet arbre, savoir ce qu’on met dedans, et comment on interagit avec l’arbre du voisin. Et ça, que ce soit la GUI ou la CLI, la difficulté est d’ordre conceptuelle. Que certains préfèrent avoir une jolie image de l’arbre en question, je veux bien le croire, mais ça reste un critère subjectif.

Si tu es hors de ces cas, tu n’aides pas la personne : tu fais le travail à sa place, de ta manière, sans respecter sa façon de faire. Ça ne l’aide ni à comprendre Git, ni à se débrouiller elle-même dans le futur : au mieux elle va copier la commande donnée quand elle aura un problème, et si ce n’est pas exactement le même ça va échouer. …

Tu soulèves de bon points qui sont déjà dans l’article, mais en l’occurrence si tu expliques les commandes, je vois pas le problème ni en quoi cela ne respecte pas sa façon de faire. Au pire ça lui demande de faire un lien mental dans sa tête en se disant "ah OK, cette commande c’est pareil que si je clique sur ce bouton puisque l’effet sur le dépôt est le même".

Mon argument n’est pas qu’il faut balancer des commandes toutes faites pour "aider", juste que c’est vachement plus simple de communiquer à coup de commandes que de se retrouver dans l’interface utilisée et dire quels bouton cliquer. D’expérience, c’est toujours un merdier sans nom quand on explique à distance à quelqu’un où cliquer. Donner des commandes par contre, c’est efficace et bête comme chou.

Évidemment, ça dépend d’avoir un peu plus de temps, d’être ferme sur la partie « regarde la doc de ton outil maintenant que tu sais ce que tu dois faire » et c’est plus compliqué que juste balancer une ligne de commande en demandant à l’autre de se démerder avec.

À la limite, si c’est toi en tant qu’aidant qui n’a pas le temps de faire une réponse propre, une variante de RTFM sera mieux pour tout le monde. Testé et approuvé.

Oui, je suis d’accord avec ça. Jusqu’à une certaine mesure cela dit, dans un cadre professionnel c’est aussi aux gens de se prendre en main et de réaliser que certains lacunes techniques pourraient valoir le coût de s’investir un peu plus dans l’apprentissage de l’outil. C’est en ça que le contexte est un peu différent de ce forum par exemple, où on aide des gens à apprendre de façon moteur explicitement. Tout le monde est là pour apprendre ici (ou du moins c’est l’objectif explicite qu’on se fixe). Au boulot pas forcément, surtout quand la personne utilise Git très ponctuellement (ce qui rend le coût d’apprentissage moins intéressant) et a juste fait une boulette un peu délicate à corriger quand on ne connait pas bien l’outil.

(@adri1 je cite ton message parce que tu es le premier à avoir sorti les arguments auxquels je réponds, mais rien de personnel hein)

SpaceFox

Oh je sais très bien, je pense qu’on a tous les deux suffisamment de bouteille ici pour ne pas se sentir attaqué par une discussion argumentée. :)

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte