Posté par raphj .
Évalué à 9.
Dernière modification le 16 avril 2020 à 08:40.
Perso, j'utilise les interface graphiques sur Git pour :
Lire la différence entre deux commits (ou deux branches), ou ce qui a été modifié depuis le dernier commit, ou ce qui a été ajouté à l'index (en vue de faire un commit)
Ajouter finement des modifications pour faire un commit par modification.
Meld pour comparer
Pour la lecture des différences, on peut remplacer git diff par git difftool --dir-diff. Cela lance Meld (ou autre, mais c'est le meilleur que je connais. En tant qu'utilisateur de KDE, je devrais réévaluer Kompare, mais il ne permettait pas l'édition et ça me gênait quand j'avais regarder - pour une revue ce n'est peut-être pas gênant).
Les dossiers sont côte à côte, et les fichiers aussi.
Regarder ce qui est indexé :
git difftool --dir-diff --cached
Regarder les modifications non indexées (et en principe, il est aussi possible de modifier les fichiers) :
git difftool --dir-diff
Comparer deux branches ou deux commits (pour faire une relecture par exemple) :
git difftool --dir-diff commit1 commit2
VS Codium pour indexer finement
VS Codium est un éditeur de code qui tend dangereusement vers l'IDE avec sa panoplie d'extension et sa gestion des dossiers. Un IDE léger, quoi. Un éditeur de code lourd. Comme vous voulez.
Il a un client Git intégré. On peut indexer et désindexer des modifications lignes par lignes avec affichages des différences avec l'index côte à côte. Il est possible d'éditer les lignes avant les indexer, pour faire des commits de ninja. Ça ne marche pas tout le temps parfaitement bien, alors ça ne remplace pas complètement git add -p et git reset -p.
Je relis ensuite les ajouts avec git diff --cached, comme ça si quelque chose n'est pas bien aligné, je le vois, et s'il y a des espaces en fin de ligne, ça s'éclaire en rouge dans le terminal. Je relis aussi régulièrement les modifications non indexées avec git add -p ou git diff, et fais une vérification avec git status (vue d'ensemble des fichiers indexés / non indexés, vérifier sur quelle branche on travaille).
GitAhead pour la gestion le dépôt
GitAhead permet de faire toutes ces choses aussi et bien plus, mais finalement avec les deux outils précédent j'en ai moins besoin. On peut indexer des bouts de modifications en les cochant, c'est sympa aussi. On a une vue d'ensemble sympathique du dépôt.
Au final, j'utilise les interfaces graphiques et la ligne de commande de concert, et mon utilisation des interfaces graphiques avec git a augmenté avec ma maîtrise de git, pas diminué :-)
Après plusieurs tâtonnements, j’utilise toujours beaucoup Git à travers la ligne de commande. Pour visionner les différences entre versions par contre je n’utilise jamais la sortie de Git directement mais plutôt Vim+Fugitive quand je développe (ou rédige un document) et qgit (ou gitg selon mon humeur) pour visualiser l’historique des versions. Pour le moment, je n’ai pas trouvé meilleur confort qu’avec cette combinaison.
Pour visualiser l'historique des versions sur une partie du code en particulier (git blame), je n'ai jamais rien trouvé de plus agréable que la commande Gblame de fugitive car elle permet d'ouvrir la diff du commit "blamé", puis d'ouvrir l'ancienne version dans la diff, que l'on peut alors "blamé" et ainsi de suite jusqu'au commit qui nous intéresse vraiment; tout ça étant possible à la ligne.
Le seul inconvénient étant que l'on peut alors se retrouver avec un nombre de buffer ouverts conséquent si on doit remonter loin dans l'historique.
Lire la différence entre deux commits (ou deux branches), ou ce qui a été modifié depuis le dernier commit, ou ce qui a été ajouté à l'index (en vue de faire un commit)
Je sais pas pourquoi, mais je trouve que lire un diff dans un terminal c’est chiant. Fait que je préfère pousser mes changements et lire le diff dans l’interface de GitLab/GitHub.
Ajouter finement des modifications pour faire un commit par modification.
Qu’est-ce qui ne va pas dans git add -p ou git commit -p ?
Posté par raphj .
Évalué à 5.
Dernière modification le 16 avril 2020 à 18:33.
Je sais pas pourquoi, mais je trouve que lire un diff dans un terminal c’est chiant. Fait que je préfère pousser mes changements et lire le diff dans l’interface de GitLab/GitHub.
Pour ma part je sais pourquoi je n'aime pas ça pour des longs diffs :
j'aime avoir les deux versions côte à côte
parfois, j'aime bien voir la modification dans son contexte, donc un outil qui affiche le code entier avec des couleurs pour montrer les modifications, c'est top. Plus lisible qu'un bloc de lignes préfixées par des plus et des moins entremêlées (même si elles sont en couleurs).
Qu’est-ce qui ne va pas dans git add -p ou git commit -p ?
C'est très bien git add -p, je l'utilise beaucoup, en particulier quand j'ai des petites modifications, ou des modifications énormes et répétitives. C'est un outil léger et rapide. Il m'arrive même assez fréquemment d'éditer les patches manuellement avec.
Mais un outil graphique avec le code entier et les modifications en couleur permettent une vue globale et lisible, et des allez-retours dans le code qui peuvent être fastidieux avec git add -p. Et git add -p refuse d'indexer une ligne quand la ligne d'après ou d'avant est modifiée sans éditer le patch à la main, quand l'outil graphique te laisse joyeusement le faire avec clic droit sur la ligne > indexer.
Dans certaines situations, le préfère git add -p, et dans d'autres, un outil graphique.
C'est en TCL/Tk, donc : c'est moche. Vraiment. Et puis un jour, je me suis dit que je devais quand même essayer de l'utiliser.
Je n'ai pas trouvé mieux pour faire de l'indexation fine, car tout a été pensé pour faire cette tâche le plus vite possible. On sélectionne les lignes, clic-droit, et les deux premières entrées du menu contextuel sont là pour (dés)indexer la section ou les lignes sélectionnées. Un clic simple sur l'icône du fichier dans le menu à gauche pour (dés)indexer le fichier entier. Ça marche, et ça va vite.
Aujourd'hui, j'utilise beaucoup Codium, et l'indexation fine est vraiment perdue dans le menu contextuel, c'est dommage…
arrêtez de répondre aux demandes d’aide en donnant des commandes Git CLI sans explications.
Ca fait du bien de lire ça… Ca change des gens dans leur tour d'ivoire qui pensent qu'il faut souffrir pour mériter de leur parler.
Perso, je sais utiliser la ligne de commande pour quand ça me sert, mais je ne vois pas d’intérêt pour git vu que les interfaces graphiques sont bien adaptées et remplissent 100% des besoins de 99% des gens. Je rempli mon cerveau avec autre chose que des commandes git (mon cerveau est plus accueillant pour les trucs visuels, comme la grande majorité de la population).
Plus que de question visuelle il me semble qu'on doit penser à ce qu'on fait réellement. Et avec git on manipule au final des fichiers textes, pas des images, des binaires ou tout autre truc où une interface graphique apporte réellement quelque chose.
Pour ma part je trouve que c'est bien de connaître la ligne de commande git quand on n'a pas encore configuré son éditeur de texe/ide, mais qu'à un moment ce qu'ont veut c'est de l'intégration avec son IDE, et ça c'est indépendant du fait que ton éditeur soit dans un terminal ou pas. Parce qu'au final quand tu utilise git c'est que tu manipules du code.
Le concept de client git indépendant, graphique ou pas, ça me semble être un retour en arrière.
Après il y a les systèmes de forking/pull requests chers à nos bitbucket/github/gitlab. On doit en parler aussi?
Dans l’autre sens, je travail avec une équipe de développeur qui n’a que des connaissances basiques de Git donc ils utilisent tous une GUI (soit leur IDE, soit des truc comme GitKraken, ou TortoiseGit). Résultat, dès qu’ils ont un problème, ils sont perdu.
La CLI a au moins un avantage : elle t’indique quoi faire presque à chaque commande.
J'ai fait un long billet qui expliquait pourquoi une GUI n'implique pas une mauvaise connaissance de Git, ni pourquoi la CLI implique une bonne connaissance de Git, et qu'en fait c'est avant tout un problème d'apprentissage, qu'une GUI peut aider sur plusieurs points.
Je suis sûr qu'on peut trouver le lien quelque part.
Néanmoins la dernière phrase de son commentaire est très importante et a été laissé de côté dans ton article si je me souviens bien:
La CLI de git explique beaucoup de choses : ce que tu dois/peux faire quand un merge n'est pas automatisable par exemple. Comment continuer le merge, abandonner le rebase…
Ce côté apprentissage de la cli de git est vraiment positif et manque souvent dans les GUI pour guider le développeur.
La gui est assez mauvaise pour l'apprentissage d'ailleurs: quand mes collègues bloqués me demandent quoi faire, je leur demande ce qu'ils veulent faire et je lance un git status qui explique souvent comment continuer/abandonner.
Un autre commentaire avait aussi souligné que la documentation en ligne de gît est aussi basée sur la CLI. La doc est aussi de mon point de vu plus intéressante pour comprendre plutôt que de faire des cliques au hasard.
Toutefois, la gui est plus pratique pour avoir une vision globale de son code. Également pour choisir les lignes de code à indexer, la souris est plus pratique. Au final, je trouve l'intégration de git dans vscode assez optimale : ce n'est pas une usine à gaz et ça me permet de faire les tâches courantes.
Quand tu es un utilisateur de Git par CLI ce que tu dis semble logique. Mais mon expérience de formateur qui a dû faire en sorte que plusieurs dizaines de personnes deviennent opérationnelles sur Git est assez différentes.
En particulier, le problème rencontré à l'utilisation de Git est généralement un problème de compréhension fonctionnelle et pas un problème de réalisation des actions. La question est que faire et non comment faire, et pour ça ni la CLI ni une GUI ne vont te donner la réponse, mais la GUI est, d'expérience, un bien meilleur support d'explication que la CLI, notamment grâce aux nombreuses informations affichées simultanément et en particulier grâce à une visualisation claire de l'arbre des commits.
De plus, une GUI bien conçue évite bien des besoins d'explications. Par exemple au lieu d'avoir besoin d'expliquer comment continuer/abandonner, elle va simplement proposer deux boutons pour le faire.
Note aussi qu'utiliser une CLI n'est jamais une excuse pour « cliquer au hasard », par contre elle donne une vue plus immédiate des possibilités de l'outil, sans aller lire une doc, et avec une hiérarchisation assez claire (s'il y a un gros bouton, c'est sans doute plus immédiatement utile que si c'est planqué au fond d'un menu).
Là encore il me semble avoir fait un long billet qui détaille ça quelque part.
Et donc, si, le sujet était bien traité. Peut-être pas sous la forme d'une phrase du genre « la CLI indique/n'indique pas quoi faire » mais dans l'explication générale du problème généralement rencontré.
Pour moi, cette problématique n'est pas valable que pour Git.
La ligne de commande est plus souple et performante. On peut faire des choses, en jouant sur les paramètres, que même les développeurs du projet n'ont pas imaginé.
Là où une interface graphique encourage l'utilisateur à l'utiliser de la bonne façon. Une IHM, c'est un peu de la documentation intégrée dans l'outil. Elle rend accessible (et decouvrable ?) des fonctionnalités de l'outil.
Cependant la CLI un coût d'apprentissage beaucoup plus élevé.
Donc souvent, il est beaucoup plus rentable d'utiliser une IHM pour des cas d'utilisation où on n'a pas intérêt à passer du temps à monter en compétence.
Par contre la CLI est souvent meilleure lorsqu'on veut faire des choses complexes ou automatiser,…
Après, pour certaines utilisations, on peut être à mi-chemin et donc utiliser la CLI et l'IHM en même temps pour jouer sur leur points forts respectifs.
En ce qui concerne la compréhension de l'outil, je dirais que ni l'un ni l'autre n'est meilleur fondamentalement . Ça dépend du principe de l'outil et de la réalisation.
En ce qui concerne spécifiquement de gît, je pense que ce qui aide le plus, c'est de comprendre son architecture (refs, objects, Hash , DAG,…) plus qu'une IHM ou la CLI. Qui est somme toute facilement compréhensible. Après, il faut tirer la pelote de laine pour comprendre de plus en plus de fonctionnalités.
Point de vue d'un développeur d'une IHM pour Git 😉 (qui n'est pas un dieu de sa ligne de commande 😁)
Je suis plutôt d'accord avec ce que tu dis.
En parcourant le liens (je n'ai pas tout lu en profondeur) j'ai l'impression que les deux principaux arguments sont :
1) la gui est auto-découvrable (pas trouvé d'autre façon de le dire), donc même si on ne sais pas quoi faire, on peut cliquer et voir ce que ça fait
2) la visualisation avec des outils dont la spécialité première est la visualisation, est plus sympa.
Mais je ne vois pas vraiment en quoi cela argumente sur le fait que l'on puisse bien savoir se servir de git sans avoir besoin de connaitre et comprendre la ligne de commande.
De ma petit éxpérience, et pour avoir mis en place une formation git à mon boulot, j'ai illuistré en parallèle une version cli et un gui des concepts que je présentais, et j'ai pu une fois de plus constater, que le défaut de toute gui git que j'ai pu trouver et tester, est que
1) Elles sont toujours incomplètes. À un moment il y a des choses que tu veux faire, mais impossible d'y arriver. Alors c'est vrai que ces choses, tu veux les faire car tu connais la CLI et donc que tu sais que c'est faisable, mais du coup l'argument de l'auto-decouvrabilité en prends un coup, car tu te retrouves limité par ce qui est présent.
2) Il peut t'arriver d'être bloqué sans pouvoir t'en sortir depuis la GUI, et ce, même en n'utilisant que la gui en question : dans mon cas, je voulais illustrer un rebase avec un commit local pour un fix qui aurait déjà été fait par quelqu'un d'autre et poussé mais avec un code légèrement différent de la version locale (ça arrive de temps en temps), la gui se retrouve bloquée, impossible de faire un "skip" du commit.
3) Elles t'imposent quasiment toutes un workflow en particulier. J'aime git en partie car je bosse avec comme j'en ai envie, et pas comme on me l'impose. C'est l'outil qui s'adapte à ma façon de faire et de gérer mon code et pas à moi de m'adapter à ce que l'outil m'impose.
Du coup j'utilise principalement les UI pour faire de la visualisation d'historique et de diff, et encore, les diff pour les gros commit, sinon la CLI me suffit.
Mais dès que j'ai besoin de faire une modification sur mon arbre de commits, j'utilise systématiquement la ligne de commande. En particulier pour les points 1) et 2) mentionnées plus haut.
Et pour en revenir au sujet et au post précédent, pour bien comprendre git, il faut bien comprendre sa façon de fonctionner. J'ajoute juste que pour moi, il faut aussi les pratiquer un peu. Et comme aucune GUI, à ma connaissance, ne permet cette pratique, la conclusion est qu'aucune GUI ne permet de bien le comprendre et l'utiliser.
# Oui : VS Codium, GitAhead, Meld
Posté par raphj . Évalué à 9. Dernière modification le 16 avril 2020 à 08:40.
Perso, j'utilise les interface graphiques sur Git pour :
Meld pour comparer
Pour la lecture des différences, on peut remplacer
git diffpargit difftool --dir-diff. Cela lance Meld (ou autre, mais c'est le meilleur que je connais. En tant qu'utilisateur de KDE, je devrais réévaluer Kompare, mais il ne permettait pas l'édition et ça me gênait quand j'avais regarder - pour une revue ce n'est peut-être pas gênant).Les dossiers sont côte à côte, et les fichiers aussi.
Regarder ce qui est indexé :
Regarder les modifications non indexées (et en principe, il est aussi possible de modifier les fichiers) :
Comparer deux branches ou deux commits (pour faire une relecture par exemple) :
VS Codium pour indexer finement
VS Codium est un éditeur de code qui tend dangereusement vers l'IDE avec sa panoplie d'extension et sa gestion des dossiers. Un IDE léger, quoi. Un éditeur de code lourd. Comme vous voulez.
Il a un client Git intégré. On peut indexer et désindexer des modifications lignes par lignes avec affichages des différences avec l'index côte à côte. Il est possible d'éditer les lignes avant les indexer, pour faire des commits de ninja. Ça ne marche pas tout le temps parfaitement bien, alors ça ne remplace pas complètement
git add -petgit reset -p.Je relis ensuite les ajouts avec
git diff --cached, comme ça si quelque chose n'est pas bien aligné, je le vois, et s'il y a des espaces en fin de ligne, ça s'éclaire en rouge dans le terminal. Je relis aussi régulièrement les modifications non indexées avecgit add -pougit diff, et fais une vérification avecgit status(vue d'ensemble des fichiers indexés / non indexés, vérifier sur quelle branche on travaille).GitAhead pour la gestion le dépôt
GitAhead permet de faire toutes ces choses aussi et bien plus, mais finalement avec les deux outils précédent j'en ai moins besoin. On peut indexer des bouts de modifications en les cochant, c'est sympa aussi. On a une vue d'ensemble sympathique du dépôt.
Au final, j'utilise les interfaces graphiques et la ligne de commande de concert, et mon utilisation des interfaces graphiques avec git a augmenté avec ma maîtrise de git, pas diminué :-)
[^] # Re: Oui : VS Codium, GitAhead, Meld
Posté par jyes . Évalué à 2.
Après plusieurs tâtonnements, j’utilise toujours beaucoup Git à travers la ligne de commande. Pour visionner les différences entre versions par contre je n’utilise jamais la sortie de Git directement mais plutôt Vim+Fugitive quand je développe (ou rédige un document) et qgit (ou gitg selon mon humeur) pour visualiser l’historique des versions. Pour le moment, je n’ai pas trouvé meilleur confort qu’avec cette combinaison.
[^] # Re: Oui : VS Codium, GitAhead, Meld
Posté par Frédéric Heulin . Évalué à 2.
Pour visualiser l'historique des versions sur une partie du code en particulier (git blame), je n'ai jamais rien trouvé de plus agréable que la commande Gblame de fugitive car elle permet d'ouvrir la diff du commit "blamé", puis d'ouvrir l'ancienne version dans la diff, que l'on peut alors "blamé" et ainsi de suite jusqu'au commit qui nous intéresse vraiment; tout ça étant possible à la ligne.
Le seul inconvénient étant que l'on peut alors se retrouver avec un nombre de buffer ouverts conséquent si on doit remonter loin dans l'historique.
[^] # Re: Oui : VS Codium, GitAhead, Meld
Posté par Anonyme . Évalué à 3.
Je sais pas pourquoi, mais je trouve que lire un diff dans un terminal c’est chiant. Fait que je préfère pousser mes changements et lire le diff dans l’interface de GitLab/GitHub.
Qu’est-ce qui ne va pas dans
git add -pougit commit -p?[^] # Re: Oui : VS Codium, GitAhead, Meld
Posté par ff9097 . Évalué à 0.
C'est loin d'être pratique
[^] # Re: Oui : VS Codium, GitAhead, Meld
Posté par raphj . Évalué à 5. Dernière modification le 16 avril 2020 à 18:33.
Pour ma part je sais pourquoi je n'aime pas ça pour des longs diffs :
C'est très bien
git add -p, je l'utilise beaucoup, en particulier quand j'ai des petites modifications, ou des modifications énormes et répétitives. C'est un outil léger et rapide. Il m'arrive même assez fréquemment d'éditer les patches manuellement avec.Mais un outil graphique avec le code entier et les modifications en couleur permettent une vue globale et lisible, et des allez-retours dans le code qui peuvent être fastidieux avec
git add -p. Etgit add -prefuse d'indexer une ligne quand la ligne d'après ou d'avant est modifiée sans éditer le patch à la main, quand l'outil graphique te laisse joyeusement le faire avec clic droit sur la ligne > indexer.Dans certaines situations, le préfère
git add -p, et dans d'autres, un outil graphique.# et Git GUI
Posté par Glandos . Évalué à 8.
Personne ne parle de git-gui ?
C'est en TCL/Tk, donc : c'est moche. Vraiment. Et puis un jour, je me suis dit que je devais quand même essayer de l'utiliser.
Je n'ai pas trouvé mieux pour faire de l'indexation fine, car tout a été pensé pour faire cette tâche le plus vite possible. On sélectionne les lignes, clic-droit, et les deux premières entrées du menu contextuel sont là pour (dés)indexer la section ou les lignes sélectionnées. Un clic simple sur l'icône du fichier dans le menu à gauche pour (dés)indexer le fichier entier. Ça marche, et ça va vite.
Aujourd'hui, j'utilise beaucoup Codium, et l'indexation fine est vraiment perdue dans le menu contextuel, c'est dommage…
# Netbeans
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Netbeans gère git de façon intuitive et son diff est très joli:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Netbeans
Posté par ben51 . Évalué à 2.
Netbeans c'est vraiment l'IDE mal aimé.
# Merci!
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca fait du bien de lire ça… Ca change des gens dans leur tour d'ivoire qui pensent qu'il faut souffrir pour mériter de leur parler.
Perso, je sais utiliser la ligne de commande pour quand ça me sert, mais je ne vois pas d’intérêt pour git vu que les interfaces graphiques sont bien adaptées et remplissent 100% des besoins de 99% des gens. Je rempli mon cerveau avec autre chose que des commandes git (mon cerveau est plus accueillant pour les trucs visuels, comme la grande majorité de la population).
[^] # Re: Merci!
Posté par Psychofox (Mastodon) . Évalué à 0.
Mouais.
Plus que de question visuelle il me semble qu'on doit penser à ce qu'on fait réellement. Et avec git on manipule au final des fichiers textes, pas des images, des binaires ou tout autre truc où une interface graphique apporte réellement quelque chose.
Pour ma part je trouve que c'est bien de connaître la ligne de commande git quand on n'a pas encore configuré son éditeur de texe/ide, mais qu'à un moment ce qu'ont veut c'est de l'intégration avec son IDE, et ça c'est indépendant du fait que ton éditeur soit dans un terminal ou pas. Parce qu'au final quand tu utilise git c'est que tu manipules du code.
Le concept de client git indépendant, graphique ou pas, ça me semble être un retour en arrière.
Après il y a les systèmes de forking/pull requests chers à nos bitbucket/github/gitlab. On doit en parler aussi?
[^] # Re: Merci!
Posté par Anonyme . Évalué à 3.
Dans l’autre sens, je travail avec une équipe de développeur qui n’a que des connaissances basiques de Git donc ils utilisent tous une GUI (soit leur IDE, soit des truc comme GitKraken, ou TortoiseGit). Résultat, dès qu’ils ont un problème, ils sont perdu.
La CLI a au moins un avantage : elle t’indique quoi faire presque à chaque commande.
[^] # Re: Merci!
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
J'ai fait un long billet qui expliquait pourquoi une GUI n'implique pas une mauvaise connaissance de Git, ni pourquoi la CLI implique une bonne connaissance de Git, et qu'en fait c'est avant tout un problème d'apprentissage, qu'une GUI peut aider sur plusieurs points.
Je suis sûr qu'on peut trouver le lien quelque part.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Merci!
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Néanmoins la dernière phrase de son commentaire est très importante et a été laissé de côté dans ton article si je me souviens bien:
La CLI de git explique beaucoup de choses : ce que tu dois/peux faire quand un merge n'est pas automatisable par exemple. Comment continuer le merge, abandonner le rebase…
Ce côté apprentissage de la cli de git est vraiment positif et manque souvent dans les GUI pour guider le développeur.
La gui est assez mauvaise pour l'apprentissage d'ailleurs: quand mes collègues bloqués me demandent quoi faire, je leur demande ce qu'ils veulent faire et je lance un
git statusqui explique souvent comment continuer/abandonner.Un autre commentaire avait aussi souligné que la documentation en ligne de gît est aussi basée sur la CLI. La doc est aussi de mon point de vu plus intéressante pour comprendre plutôt que de faire des cliques au hasard.
Toutefois, la gui est plus pratique pour avoir une vision globale de son code. Également pour choisir les lignes de code à indexer, la souris est plus pratique. Au final, je trouve l'intégration de git dans vscode assez optimale : ce n'est pas une usine à gaz et ça me permet de faire les tâches courantes.
[^] # Re: Merci!
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Quand tu es un utilisateur de Git par CLI ce que tu dis semble logique. Mais mon expérience de formateur qui a dû faire en sorte que plusieurs dizaines de personnes deviennent opérationnelles sur Git est assez différentes.
En particulier, le problème rencontré à l'utilisation de Git est généralement un problème de compréhension fonctionnelle et pas un problème de réalisation des actions. La question est que faire et non comment faire, et pour ça ni la CLI ni une GUI ne vont te donner la réponse, mais la GUI est, d'expérience, un bien meilleur support d'explication que la CLI, notamment grâce aux nombreuses informations affichées simultanément et en particulier grâce à une visualisation claire de l'arbre des commits.
De plus, une GUI bien conçue évite bien des besoins d'explications. Par exemple au lieu d'avoir besoin d'expliquer comment continuer/abandonner, elle va simplement proposer deux boutons pour le faire.
Note aussi qu'utiliser une CLI n'est jamais une excuse pour « cliquer au hasard », par contre elle donne une vue plus immédiate des possibilités de l'outil, sans aller lire une doc, et avec une hiérarchisation assez claire (s'il y a un gros bouton, c'est sans doute plus immédiatement utile que si c'est planqué au fond d'un menu).
Là encore il me semble avoir fait un long billet qui détaille ça quelque part.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Merci!
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Et donc, si, le sujet était bien traité. Peut-être pas sous la forme d'une phrase du genre « la CLI indique/n'indique pas quoi faire » mais dans l'explication générale du problème généralement rencontré.
La connaissance libre : https://zestedesavoir.com
# tig
Posté par Pol' uX (site web personnel) . Évalué à 4.
https://jonas.github.io/tig/
L'essayer c'est l'adopter.
Adhérer à l'April, ça vous tente ?
# Ça manque de xkcd (1597)
Posté par kna . Évalué à 10.
# CLI vs GUI
Posté par cosmocat . Évalué à 5.
Pour moi, cette problématique n'est pas valable que pour Git.
La ligne de commande est plus souple et performante. On peut faire des choses, en jouant sur les paramètres, que même les développeurs du projet n'ont pas imaginé.
Là où une interface graphique encourage l'utilisateur à l'utiliser de la bonne façon. Une IHM, c'est un peu de la documentation intégrée dans l'outil. Elle rend accessible (et decouvrable ?) des fonctionnalités de l'outil.
Cependant la CLI un coût d'apprentissage beaucoup plus élevé.
Donc souvent, il est beaucoup plus rentable d'utiliser une IHM pour des cas d'utilisation où on n'a pas intérêt à passer du temps à monter en compétence.
Par contre la CLI est souvent meilleure lorsqu'on veut faire des choses complexes ou automatiser,…
Après, pour certaines utilisations, on peut être à mi-chemin et donc utiliser la CLI et l'IHM en même temps pour jouer sur leur points forts respectifs.
En ce qui concerne la compréhension de l'outil, je dirais que ni l'un ni l'autre n'est meilleur fondamentalement . Ça dépend du principe de l'outil et de la réalisation.
En ce qui concerne spécifiquement de gît, je pense que ce qui aide le plus, c'est de comprendre son architecture (refs, objects, Hash , DAG,…) plus qu'une IHM ou la CLI. Qui est somme toute facilement compréhensible. Après, il faut tirer la pelote de laine pour comprendre de plus en plus de fonctionnalités.
Point de vue d'un développeur d'une IHM pour Git 😉 (qui n'est pas un dieu de sa ligne de commande 😁)
[^] # Re: CLI vs GUI
Posté par moi1392 . Évalué à 2.
Je suis plutôt d'accord avec ce que tu dis.
En parcourant le liens (je n'ai pas tout lu en profondeur) j'ai l'impression que les deux principaux arguments sont :
1) la gui est auto-découvrable (pas trouvé d'autre façon de le dire), donc même si on ne sais pas quoi faire, on peut cliquer et voir ce que ça fait
2) la visualisation avec des outils dont la spécialité première est la visualisation, est plus sympa.
Mais je ne vois pas vraiment en quoi cela argumente sur le fait que l'on puisse bien savoir se servir de git sans avoir besoin de connaitre et comprendre la ligne de commande.
De ma petit éxpérience, et pour avoir mis en place une formation git à mon boulot, j'ai illuistré en parallèle une version cli et un gui des concepts que je présentais, et j'ai pu une fois de plus constater, que le défaut de toute gui git que j'ai pu trouver et tester, est que
1) Elles sont toujours incomplètes. À un moment il y a des choses que tu veux faire, mais impossible d'y arriver. Alors c'est vrai que ces choses, tu veux les faire car tu connais la CLI et donc que tu sais que c'est faisable, mais du coup l'argument de l'auto-decouvrabilité en prends un coup, car tu te retrouves limité par ce qui est présent.
2) Il peut t'arriver d'être bloqué sans pouvoir t'en sortir depuis la GUI, et ce, même en n'utilisant que la gui en question : dans mon cas, je voulais illustrer un rebase avec un commit local pour un fix qui aurait déjà été fait par quelqu'un d'autre et poussé mais avec un code légèrement différent de la version locale (ça arrive de temps en temps), la gui se retrouve bloquée, impossible de faire un "skip" du commit.
3) Elles t'imposent quasiment toutes un workflow en particulier. J'aime git en partie car je bosse avec comme j'en ai envie, et pas comme on me l'impose. C'est l'outil qui s'adapte à ma façon de faire et de gérer mon code et pas à moi de m'adapter à ce que l'outil m'impose.
Du coup j'utilise principalement les UI pour faire de la visualisation d'historique et de diff, et encore, les diff pour les gros commit, sinon la CLI me suffit.
Mais dès que j'ai besoin de faire une modification sur mon arbre de commits, j'utilise systématiquement la ligne de commande. En particulier pour les points 1) et 2) mentionnées plus haut.
Et pour en revenir au sujet et au post précédent, pour bien comprendre git, il faut bien comprendre sa façon de fonctionner. J'ajoute juste que pour moi, il faut aussi les pratiquer un peu. Et comme aucune GUI, à ma connaissance, ne permet cette pratique, la conclusion est qu'aucune GUI ne permet de bien le comprendre et l'utiliser.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.