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.
[^] # Re: CLI vs GUI
Posté par moi1392 . En réponse au lien Git : la GUI est votre amie !. É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.