[Résolu] Git, GUI et Ligne de commande

Salut,

Je suis en train de prendre quelques jours pour bosser git suite aux conseils de MatthieuR (confer). Chacun sa courbe d'apprentissage hein...
J'ai donc commencé par le tuto de Grafikart, et je peux comprendre l'intérêt de la ligne de commande pour appréhender le sujet avant de passer à une interface graphique.
Ce que je ne comprends pas, c'est l'intérêt pour certains de continuer à utiliser la ligne de commande ultérieurement. Et cette question ne s'applique donc pas uniquement à Git.
Je fais parti des gens qui ont débuté leur formation en informatique en apprenant DOS, Unix... J'ai donc connu la ligne de commande il y a plus de 20 ans, l'obligation de faire des cd mount sys & Cie et franchement, l'interface graphique malgré ses nombreux défauts a plus d'avantages sur le plan de l'ergonomie cognitive, particulièrement sur le critère de l'utilisabilité. Dans une autre vie où je développais des applis, j'ai aussi connu le versionning du code, mais j'avais sous la main des outils visuels et jamais il ne m'a été demandé de revenir à la ligne de commande. Ce n'était d'ailleurs pas disponible.
Je ne pense pas que réutiliser les cartes perforées augmenterait la célérité des workflow. Alors quel est l'intérêt principal d'utiliser la ligne de commande ?
Modifié par Manhattan (17 Aug 2016 - 14:25)

Salut

Sur pas mal de logiciel qui accepte les instructions par ligne de commande, on a bien souvent accès à bien plus de possibilité que celle proposé par l'IHM.

Ensuite, ça permets aussi de pouvoir automatiser des tâches depuis l’extérieur, pratique pour des tâches répétitives.

Il y a plein d'avantage à la ligne de commande, autre que la simple utilisation "standard" d'une interface/logiciel.

Ce n'est que mon point de vue

Bonjour !

Je vais me hasarder à une explication sur cet "amour de la ligne de commande"...

D'abord, quand on tient quelque chose qui fonctionne et que l'on a mis du temps à apprendre, on n'a pas forcément envie de se mettre à apprendre une autre façon de faire surtout quand on n'est pas certain de la supériorité de la nouvelle méthode : on sait que l'on peut faire de cette façon, ça fonctionne, on prend l'habitude, on peut se concentrer sur ce qu'on ne sait pas faire...

Et ensuite, peut-être que dans ce monde où tout change si vite, où il faut sans cesse s'adapter à de nouvelles façons de faire, la ligne de commande a l'air de quelque chose de solide, de fiable qui ne va pas se démoder facilement et que l'on peut sans risque prendre le temps d'apprendre...

Voilà mon opinion.

Salut !

Quand on s'est mis à git au taff j'ai direct pris l'interface graphique et au final je suis passé aux lignes de commandes quelques jours plus tard. Comme le dit Super_baloo8 l'IHM proposait moins de choses et surtout c'était vaaaachement moins pratique pour comprendre certaines choses (pour les conflits de merge essentiellement).
Au final c'était pas super compliqué, on comprend ce qu'on fait et on ne fait que ce qu'on veut faire.

Bonne journée

Ok. J'ai compris.
> plus intelligible
> plus de choses
> plus fiable

Bon, ben j'continue d'apprendre mes ptites commandes... ^^

Sans oublier cet argument :

Super_baloo8 a écrit :
ça permets aussi de pouvoir automatiser des tâches depuis l’extérieur, pratique pour des tâches répétitives.

Hello !
(Désolé, j'arrive un peu après coup)

Il y a des différences fondamentales de fonctionnement entre la ligne de commande et une interface graphique.

Dans une interface graphique, une fenêtre te propose différentes fonctionnalités. Si c'est bien fait, tu n'as pas (ou très peu) besoin d'apprendre le fonctionnement de l'interface. Ainsi, pour exécuter une commande, tu dois chercher l'élément graphique te permettant de le faire, puis effectuer une interaction quelconque afin de déclencher l'action voulue.

En ligne de commande, tu est censé connaître les commandes qui te permettent d'exécuter certaines tâches. En clair, ça demande beaucoup plus d'apprentissage, mais c'est aussi beaucoup plus rapide, puisque, quand tu l'utilises, tu sautes l'étape "chercher le bouton qui fait ça".

Tout ça, plus tous les autres avantages décrits plus haut

Oh mais j'ai pas fermé le sujet et je prends tout ^^
Ce qui m'inquiète un peu, ayant un workflow encore ancestral basé sur une version dév en ligne + brackets branché dessus avec EQftp qui à chaque save upload et donc pas de versionning , ce qui m'inquiète donc, c'est que je ne sais pas encore comment je vais adapter tout ça. Mes sites de dév sont sur mon mutu pro ovh, et je compte toujours utiliser brackets, qui via une extension propose de gérer git. Mais je peux aussi (c'est ce que je fais actuellement durant mon apprentissage) avoir brackets dans un coin, Cmder dans l'autre, et un navigateur plus loin. J'ai pas précisé mais windows 10 pour pas aider

P.S. rien à voir mais je viens de lire sur ton site ton "absolument tout ici est exactement comme on le voit dans les films et les séries " et ça m'a fait sourire : c'est exactement ce que je me suis dit lorsque j'suis parti aux usa avec un pote il y a bientôt 15 ans en mode guide du routard sac à dos durant quelques semaines. Entre les bus Greyhound qui s'arrêtent dans des coins paumés type Twin Peaks où tu manges un sandwiche au poisson chat, New York où tu tournes la rue et tu tombes sur des écoliers en rang d'oignon en train de réciter l'hymne national, et puis les distances, tout est 10 fois plus grand, oui, c'est exactement comme dans les séries. Faut vraiment le faire à pied ce périple (enfin, entre les villes le bus et la voiture louée c'est pas mal non plus ^^)
Modifié par Manhattan (04 Aug 2016 - 16:53)

S'il n'y a qu'un seul outil en ligne de commande que je peut te conseiller, pour créer facilement un workflow pour tes projets web, qui va du plus simple au plus complexe, c'est Gulp (voir l'excellent article de Raphaël : http://www.alsacreations.com/tuto/lire/1686-introduction-a-gulp.html). Ca demande un tout petit peut d'apprentissage, mais si tu connais déjà JavaScript, ça va très vite.

Avec Gulp, tu peux en un clic (ou une commande) compiler et minifier tes SASS en CSS, compiler et minifier ton TS en JS, optimiser tes images, commit le tout et uploader par FTP (Bon, c'est un exemple un peu extrême pour ton cas, mais c'est pour te donner une idée).

PS: (rien à voir) Il a l'air vraiment super sympa ton voyage Pour l'instant, j'ai fait le Minnesota et la Louisianne et tout était absolument superbe à voir. Après-demain, je pars pour un road trip dans le Dakota du Sud et ça promet d'être encore mieux

Je comptais bosser Gulp après Git. Il me paraissait logique de connaître le versioning avant mais je me trompe peut-être.

Pour le voyage, j'avais fait la côte Est, de New york à Atlanta puis jusqu'à Memphis Tenessee. 12 heures de bus Greyhound pour remonter d'Atlanta à Washington faut le faire, mais faut le faire qu'une fois hein parce que bon...

Manhattan a écrit :
Salut,
Je suis en train de prendre quelques jours pour bosser git suite aux conseils de MatthieuR (confer). Chacun sa courbe d'apprentissage hein...
J'ai donc commencé par le tuto de Grafikart, et je peux comprendre l'intérêt de la ligne de commande pour appréhender le sujet avant de passer à une interface graphique.
Ce que je ne comprends pas, c'est l'intérêt pour certains de continuer à utiliser la ligne de commande ultérieurement. Et cette question ne s'applique donc pas uniquement à Git.
Je fais parti des gens qui ont débuté leur formation en informatique en apprenant DOS, Unix... J'ai donc connu la ligne de commande il y a plus de 20 ans, l'obligation de faire des cd mount sys & Cie et franchement, l'interface graphique malgré ses nombreux défauts a plus d'avantages sur le plan de l'ergonomie cognitive, particulièrement sur le critère de l'utilisabilité. Dans une autre vie où je développais des applis, j'ai aussi connu le versionning du code, mais j'avais sous la main des outils visuels et jamais il ne m'a été demandé de revenir à la ligne de commande. Ce n'était d'ailleurs pas disponible.
Je ne pense pas que réutiliser les cartes perforées augmenterait la célérité des workflow. Alors quel est l'intérêt principal d'utiliser la ligne de commande ?

Durant ma vie professionnelle, j'ai pratiqué aussi bien les IHM que la ligne de commande, qu'il s'agisse de batch MS-DOS ou Unix et je dois bien avouer avoir une nette préférence pour l'IHM car elle s'avère beaucoup plus productive dans mon cas, notamment pour un meilleur confort visuel.
Même sous Windows, les traitements répétitifs peuvent parfaitement être modularisés sous forme de fichiers batch.
A contrario, l'un de mes collègues ne jure que par la ligne de commande Unix, et l'édition de texte à la "edlin" (les anciens comprendront...). Un vrai calvaire pour le commun des mortels, mais qui convient parfaitement à sa façon de travailler.
La conclusion... bin comme souvent tout est affaire de goût et chacun doit pouvoir opter pour l'environnement qui lui convient le mieux.
Une IHM ergonomiquement bien conçue, c'est à dire offrant tous les paramètrages possibles d'un logiciel, accessibles très rapidement par menu ou raccourcis clavier, peut s'avérer tout aussi, voire plus, performante qu'un traitement par lot ou une ligne de commande.
Qui plus est, l'aide contextuelle et/ou intégrée sera, par nature, plus aisément accessible en IHM que via l'affichage en ligne sur un écran (le fameux "-help").
A chacun de choisir sa chapelle, donc.
Modifié par sepecat (04 Aug 2016 - 20:26)

C'était un peu mon impression que plus on est "ancien" plus on est tourné vers l'interface graphique et moins on a goûté jeune à la ligne de commande, plus on la pratique après.
Ensuite, si l'interface graphique est moins compétente, c'est que le logiciel est mal conçu.
Maintenant, je n'en connais pas assez sur git pour juger

De toute façon, si vous compter utiliser Git sous l'égide de Github, il faut savoir que celui-ci a développé un excellent outil graphique : Github Desktop. Disponible sur Mac et Windows. A tester absolument.

Personnellement, après avoir un peu tripoté la ligne de commande, je ne me sert plus que de cela. Mais je n'ai que rarement besoin d'effectuer des manipulations complexes. Je fais bien plus de lignes de commande avec Gulp que je n'en fais pour Github.
Modifié par Olivier C (05 Aug 2016 - 08:58)

Bonjour,

Et bien je pensais m'orienter plutôt vers une version gratuite pour des projets qui ne sont pas open source donc bitbucket. Mais je n'ai pas abandonné la ligne de commande pour l'instant

Bonjour,

Toujours dans la réorganisation globale de mon workflow...

Multiples Questions subsidiaires :
est-ce que certains utilisent les 2 en association (GUI+CLI) ?

Par exemple actuellement dans mon apprentissage j'effectue les opérations avec Powershell mais je regarde ce que ça donne avec Ungit.

Dans le magnifique article de Raphaël sur son workflow :
http://www.alsacreations.com/tuto/lire/1685-ebauche-de-workflow-gulp-taches-uncss-includes-critical-css.html
Je dois être idiot, mais où vient se placer Git ?

Enfin, j'ai cru comprendre que pour un projet wordpress, il fallait réorganiser un peu les dossiers du projet pour qu'ils soient versionnables aisément.
Des conseils à ce propos ?

Je voudrais tester sur un exemple concret à savoir la conception d'un thème de base pour les petits budgets en partant sur le thème quarks, j'imagine utiliser une partie mon hébergement ovh pour mon dépot git, et je ne sais pas exactement comment commencer.
Modifié par Manhattan (06 Aug 2016 - 12:29)

Manhattan a écrit :
Dans le magnifique article de Raphaël sur son workflow :
http://www.alsacreations.com/tuto/lire/1685-ebauche-de-workflow-gulp-taches-uncss-includes-critical-css.html
Je dois être idiot, mais où vient se placer Git ?

Git est un logiciel indépendant de Gulp et autres task runners. Il crée son propre environnement.

Merci Olivier.

Une autre question subsidiaire de fin de week end :

Pour chaque site web hébergé sur mon mutu ovh, j'ai 2 versions : une Test et une Pré-prod. Accessibles en sous-domaines. (je considère que la production c'est la version chez le client sur son propre serveur).
J'ai donc :
client1.monsiteamoi.com <- pré-prod
clt1.monsiteamoi.com <- test
etc.

En fonction de ce que j'ai continué d'apprendre ce we sur git, je pensais conserver cette architecture en imaginant :
Mon master qui pointerait sur ma pré-prod, une branche Dev qui pointerait sur mon Test et probablement une branche pour chaque nouvelle grosse "feature".

Mais ensuite je ne sais pas trop où placer mes dépôts (suis tout seul à bosser sur le code).

Bitbucket pour tous les dépôts avec les contenus chez ovh (sais même pas si c'est faisable) ?
Tous mes dépôts en local sur mon ordi ?
Voire parce que ça semble possible maintenant sur des mutu : mes dépôts sur mon mutu ovh mais ça veut dire dans www et je crois que c'est pas trop top...?

Dans l'attente d'une réponse, bonne fin de we

Salut,

Pour la question sur GIT, perso pour mes sites, de plus en plus je fais en sorte avec les hook que quand je push sur master, ça fait un pull dans le répertoire web.
Et parralèlement, quand je push sur une branche qui s'appelle dev-quelque-chose, un pull est fait sur un site de test.

L'avantage c'est qu'on n'a plus besoin de se casser les pieds avec du FTP. ON fait une modif, on la commit, on la push, et on peut tester immédiatement (le temps que ça upload).

Après le problème c'est que sur un hébergement mutualisé, souvent, c'est pas faisable. Il faut s'y prendre autrement, soit avec un hook local, soit en installant un webhook qui fait télécharger le site d'une autre façon.
Ou alors on ne peut pas vraiment inclure GIT dans le processus et il faut en rester au script indépendant style taskrunner qui watch et qui upload sans tenir compte de GIT. ca marche aussi.


Maintenant pour le débat plus général ligne de commande vs interface graphique, je pense que c'est effectivement surtout une question de choix personnel au final.
Cependant, je pense que la vérité, c'est une combinaison astucieuse des deux

Depuis quelques annés on peut s'apercevoir que la ligne de commande s'est en quelque sorte réinvitée dans les interfaces graphiques, notamment sous forme de barre qui permet d'exécuter rapidement quelque chose ou de faire des recherches.
Par exemple le menu démarrer depuis WIndows 7, la barre de recherche dans l'explorateur et le panneau de configuration, la barre d'exécution rapide de certains IDE qui permettent d'entrer fichier.ext:10 pour aller directement à la ligne 10 de fichier.ext ou +100 pour avancer de 100 lignes, et bien sûr la barre d'adresse des navigateurs qui lance directement une recherche Google...

En fait on s'est aperçu de quelque chose de décisif:

Les interfaces graphiques, c'est bien quand on ne connaît pas trop un logiciel / qu'on le découvre ou quand on n'est pas trop à la'ise avec, car on peut rapidement avoir une vue d'ensemble de ses fonctionnalités sans faire trop d'effort intellectuel. Ca se prête bien à l'exploration: on essaie, ah non c'est pas ça, on revient en arrière, on réessaie, une aide contextuelle nous guide...
La ligne de commande, de son côté, implique qu'il faut nécessairement lire le manuel / apprendre la syntaxe, et comprendre comment le logiciel fonctionne (au moins quelques bases), avant de pouvoir faire quoi que ce soit. Aux premiers abords ça rebute toujours, même les informaticiens.

Par contre:

Quand on maîtrise un logiciel et qu'on sait précisément ce qu'on veut/peut/doit faire avec, taper des commandes, ça va beaucoup plus vite que de cliquer frénétiquement sur OK.
ca a été prouvé par des études très sérieuses: on perd beaucoup de temps pour faire des va-et-vient entre le clavier et la souris, pour retrouver dans quel menu est cette p*#@% d'option qu'on n'utilise tous les tremblements de terre et qu'on sait qu'elle est là mais où b*#%del, et les enchaînements répétitifs de boîtes de dialogue longues et complexes finissent par énerver car on a l'impression de faire un travail de singe.
ET en plus on a l'argument bonus de l'automatisation.

En ce qui me concerne personnellement, mon curseur se situe un peu entre les deux je crois:
D'un côté, GIT en interface graphique je trouve que c'est absolument pas efficace, je suis le premier à sortir Node.js/python/PHP-CLI dès lors qu'une tâche est un peu répétitive, je préfère largement markdown ou LaTeX à Word, et je suis le premier à déplorer l'absence d'une fonction de recherche de commande dans ce même Word quand je suis obligé de l'utiliser...

Par contre de l'autre côté, vim me saoule, je n'ai pas envie de me surcharger inutilement la tête à devoir compter combien de lignes ou de caractères je dois sélectionner/copier/couper/supprimer et je n'arrive absolument pas à comprendre comment on peut aimer une telle contrainte; même si je suis persuadé que les habitués de ces logiciels vont 3 fois plus vite qu'avec Nodepad++/eclipse/VS/etc.
De même je n'arrive pas à comprendre comment certains peuvent encore aimer naviguer avec Lynx ou W3M... même si je sais que ça vire 99% de la m*@#% qui pourrit inutilement le web.

Merci pour ta réponse Quentin,

Oui, j'ai cru comprendre que c'était moyen sur un hébergement mutualisé ovh.
J'ai bien trouvé ce tuto, mais à voir :
http://darklg.me/2016/03/deployer-un-site-avec-git-sur-un-hebergement-mutualise-ovh-ou-autre/
Ensuite, c'est pas le prix qui m'empêche de prendre un kimsufi, c'est qu'il me faudrait bosser en plus des notions d'administration serveur que je n'ai absolument pas... et niveau temps, ça serait juste si je veux manger.

Et je veux rester sur git maintenant que j'ai commencé à mettre les mains dans le cambouis.

Je pense que tu as raison sur le débat sur l'interface : de plus en plus dans mon apprentissage de git je réalise que les 2 peuvent cohabiter, que les 2 cohabitent souvent, d'ailleurs certains utilisent leur IDE pour certaines tâches ultra simples et la ligne de commande pour des choses plus avancées.
Ensuite tout évolue. Il y a 20 ans, je n'avais pas un clavier incorporé sur ma souris donc je quittais rarement mon clavier. Maintenant, je copie/coupe/colle tantôt au clavier, tantôt à la souris (clavier) en fonction de l'endroit où je suis déjà. Un autre endroit où le clavier est très important, c'est sous les outils graphiques. Si je devais faire un CTRL MAJ ALT E sous photoshop via les menus, je saurais même plus où le trouver. Et en effet, les interfaces ont évoluées pour ré-intégrer des champs de saisie pour taper directement des commandes et c'est pas plus mal. Concernant le 3 fois plus vite, je ne sais pas. Sur toutes les vidéos que j'ai regardées sur git en ligne de commande, et j'en ai mangé quelques-unes, j'ai vu les gars se planter, faire des retour arrière multiples pour éviter de retaper un commit, se planter et recommencer etc...
Bref, git en ligne de commande commence à m'amuser, donc je vais bien arriver à le digérer comme tout le monde.
Maintenant concernant les lieux de mes dépôts, je sens que je vais devoir faire des essais avancés avant de trouver véritablement l'organisation qui me sera la plus pratique. J'ai pourtant cherché s'il existait des tutos orientés lonesome developer mais j'ai pas trouvé.


Modifié par Manhattan (08 Aug 2016 - 13:13)