GitHub 2.0 pour Windows est disponible : refonte de l'interface au programme

GitHub 2.0 pour Windows est disponible : refonte de l’interface au programme

Ne manque plus que Git 3.0

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

10/06/2014 3 minutes
60

GitHub 2.0 pour Windows est disponible : refonte de l'interface au programme

GitHub vient d'annoncer la mise en ligne de la mouture 2.0 de son client pour Windows. Celle-ci se focalise sur une refonte générale de l'ergonomie, ce qui n'était pas un mal. Elle apporte aussi quelques petites améliorations au passage.

GitHub Windows 2.0

 

Afin de faciliter l'utilisation de Git à ses adeptes, GitHub a annoncé il y a deux ans la mise en ligne d'un client dédié à Windows. Celui-ci reprenait alors une interface simple exploitant WPF, et plusieurs panneaux, de manière à réduire le plus possible l'utilisation des lignes de commande. Après une évolution de la branche 1.x jusqu'à la mouture 1.3.3, c'est aujourd'hui la 2.0 qui est mise en ligne, avec une refonte complète de l'ergonomie.

Une interface entièrement repensée

On retrouve bien entendu cette grande fenêtre blanche unique, mais l'utilisation des différents panneaux a été grandement réduite. En effet, toutes les principales actions sont désormais directement accessibles, et l'espace a été plutôt bien repensé. La colonne de gauche affiche ainsi désormais tous vos dépôts locaux avec un filtre. Pour interagir avec ceux présents sur GitHub, vous devrez passez par le bouton « + » qui fera apparaître un menu vous permettant de créer un dépôt ou d'en cloner un existant. 

 

La seconde colonne contiendra l'historique du dépôt sélectionné et sera surmontée d'un sélecteur vous permettant de changer de branche ou d'en créer une nouvelle. Un panneau sera par contre toujours nécessaire afin d'assurer la gestion d'opérations plus complexes comme un « merge », mais aussi la suppression ou l'arrêt de la publication sur le serveur.

 

La partie de droite, enfin, reprendra pour l'essentiel les détails de chaque commit : son nom, son hash, son résumé, mais aussi les modifications effectuées à chaque fichier. Des boutons vous permettront de le voir sur le site de GitHub ou d'effectuer un retour en arrière (Revert) via un nouveau commit qui sera automatiquement créé. La synchronisation de la branche en cours passera toujours par un bouton dédié qui sera désormais directement accessible tout comme la roue crantée donnant accès à des raccourcis vers l'explorateur de fichier, Git Shell ou GitHub, mais aussi aux paramètres du dépôt et aux options. 

Des fonctionnalités qui restent globalement les mêmes à quelques détails près

Ces dernières vous permettront de gérer votre compte GitHub, mais aussi de choisir le dossier de clonage ou le shell utilisé par défaut (cmd, Git Bash, PowerShell ou un que vous aurez vous-même indiqué). Les notes de version précisent aussi quelques petits détails qui ont été modifiés çà et là, ainsi que quelques corrections de bugs ont été effectuées pour l'occasion, notamment au niveau de la mouture 2.0.1.

 

Notez par contre que Git 2.0 ne semble pas encore utilisé. Celui-ci a en effet été publié il y a peu avec plusieurs nouveautés, mais pas encore assez aux yeux de certains qui en appellent à une refonte plus en profondeur de l'outil de gestion de versions. Ce qui ne serait peut-être pas un mal.

 

Pour en savoir plus ou télécharger GitHub pour Windows 2.0, c'est par ici que ça se passe.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une interface entièrement repensée

Des fonctionnalités qui restent globalement les mêmes à quelques détails près

Fermer

Commentaires (60)




Notez par contre que Git 2.0 ne semble pas encore utilisé.



Elle est en effet pas encore dispo sous windows (qui en est toujours à la 1.9.2).

J’avais cru comprendre que la plateforme windows serait moins à la bourre à ce niveau là mais c’est pas encore simultané avec la sortie sur les autres plateformes :(


Pour bosser sérieusement avec Git je recommande SmartGit. Après en avoir testé plusieurs c’est le plus complet et productif je trouve.








wagaf a écrit :



Pour bosser sérieusement avec Git je recommande SmartGit. Après en avoir testé plusieurs c’est le plus complet et productif je trouve.





Pour bosser sérieusement, c’est ligne de commande et point barre.









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.





Et des papillons. Car les vrai développeurs utilisent des papillons.









tazvld a écrit :



Et des papillons. Car les vrai développeurs utilisent des papillons.





Evidemment. Ca va sans dire.









tazvld a écrit :



Et des papillons. Car les vrai développeurs utilisent des papillons.





Les champignons ça marche aussi ?



Ouai mais bon, sourcetree c’est mieux et on peut ajouter bitbucket <img data-src=" />








seb2411 a écrit :



Les champignons ça marche aussi ?







Non, papillons uniquement (et emacs –qui possède un client git–) :http://xkcd.com/378/









wagaf a écrit :



Pour bosser sérieusement avec Git je recommande SmartGit. Après en avoir testé plusieurs c’est le plus complet et productif je trouve.







Pour ceux qui peuvent se permettre de mettre de l’acheter. Pour les autres, il y a Sourcetree ou GitExtensions….









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.







Pas tout le temps…

Pour construire un commit, je préfère largement une IHM à la ligne de commande. Surtout pour ajouter des parties de fichiers.



Pour consulter le log en graphe également.



Mais pour ceux qui veulent l’avantage d’une IHM tout en restant dans la console, il y a également le très bon ‘tig’!





La ligne de commande c’est génial, j’en mange tous les jours et mes cheveux deviennent plus soyeux





Déjà Vendredi?








garvek a écrit :



Déjà Vendredi?





Non, c’est juste la réalité.









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.





+42

D’ailleurs a ce sujethttps://www.kickstarter.com/projects/xiki/xiki-the-command-revolution







tazvld a écrit :



Et des papillons. Car les vrai développeurs utilisent des papillons.





sans oublier d’aller voir ce cher docteur <img data-src=" />









cosmocat a écrit :



Pour ceux qui peuvent se permettre de mettre de l’acheter. Pour les autres, il y a Sourcetree ou GitExtensions….





Sourcetree pas dispo pour linux…





gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.





Si tu code comme à l’époque de SVN, oui <img data-src=" />



Perso Git en ligne de commande, j’en ai eu une expérience très amère, avec pertes de données importantes et un support technique de la part des git fan équivalent à “tu sais pas coder en langage machine ? stfu noob kikoo lol ctb”.



Avec une doc nébuleuse, des commandes dont le mot n’a pas de rapport avec ce qu’elles font (ex = commit pour revert, reset hard ou soft qui servent à manipuler l’historique, et pull qui sert à péter ton répo à moins d’avoir configuré plein de truc en amont ou de faire le fetch + merge à la main), un contrôle proche du 0 sur ce que tu peux faire à moins de manipuler les chunks directement sous forme de patchs, impossible de maj un seul fichier (tu ne peux récupérer qu’un historique entier de tout le répo), j’avoue que Git n’est pas un outil qui me donne envie.



A l’inverse les outils graphiques et surtout l’interface Web de Github m’ont permis de pouvoir bosser avec d’autres git users sans souci particulier …








wagaf a écrit :



Sourcetree pas dispo pour linux…



Si tu code comme à l’époque de SVN, oui <img data-src=" />







Véridique : dans ma boîte on est toujours sur CVS. SVN c’est encore trop un truc de hipster pour mes patrons. Déjà qu’ils me prennent pour un hippy quand je parle de CSS, je n’ai pas encore oser prononcer des mots comme angular, node ou de lambda Java 8…









Yangzebul a écrit :



Véridique : dans ma boîte on est toujours sur CVS. SVN c’est encore trop un truc de hipster pour mes patrons. Déjà qu’ils me prennent pour un hippy quand je parle de CSS, je n’ai pas encore oser prononcer des mots comme angular, node ou de lambda Java 8…





sale hippy barbu fumeur de joints va ! <img data-src=" />



<img data-src=" /> =========================&gt;[]



Bonjour ,



Pourquoi vous ne commencé pas l’article par à quoi sert ce logiciel?








Yangzebul a écrit :



Véridique : dans ma boîte on est toujours sur CVS. SVN c’est encore trop un truc de hipster pour mes patrons. Déjà qu’ils me prennent pour un hippy quand je parle de CSS, je n’ai pas encore oser prononcer des mots comme angular, node ou de lambda Java 8…





c’est sur que pour coder en Ada, même la souris c’est trop hipster.









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.





Un Diff en mode texte… <img data-src=" />









code a écrit :



Bonjour ,



Pourquoi vous ne commencé pas l’article par à quoi sert ce logiciel?





C’est un logiciel de versionnage.

Quand on développe une application (ou un site oueb), on veut garder les différentes versions en cours de développement. Si un jour tu modifies une partie du code et que tu fais de la merde, tu peux toujours revenir à une plus vieille version et voir les différences avec la version actuelle pour traquer le problème.









porecreat a écrit :



Un Diff en mode texte… <img data-src=" />





Quand je vois des collègues qui font ça <img data-src=" />



J’ai mis un alias pour AU MOINS mettre de la couleur dans les diff. C’est plus lisible mais pas plus éditable.

S’il y a bien une chose qui est bien plus pratique à la GUI qu’à la ligne de commande c’est ça.









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.







Oui, il parait que les vrais développeurs utilisent la ligne de commande uniquement. Il parait aussi que ceux qui ne le font pas sont systématiquement des sous-races.









garvek a écrit :



Avec une doc nébuleuse, des commandes dont le mot n’a pas de rapport avec ce qu’elles font (ex = commit pour revert, reset hard ou soft qui servent à manipuler l’historique, et pull qui sert à péter ton répo à moins d’avoir configuré plein de truc en amont ou de faire le fetch + merge à la main), un contrôle proche du 0 sur ce que tu peux faire à moins de manipuler les chunks directement sous forme de patchs, impossible de maj un seul fichier (tu ne peux récupérer qu’un historique entier de tout le répo), j’avoue que Git n’est pas un outil qui me donne envie.





Il semble qu’encore aujourd’hui tu n’a pas saisi grand chose au fonctionnement de Git, pas une seule de tes affirmations n’est juste <img data-src=" /> Mais en effet quand on appréhende l’outil comme si c’était CVS sans connaître le fonctionnement des branches, tags etc. on est vite perdu, ce n’est pas une critique.



Il est quasi impossible de perdre des données avec Git, même après un reset Hard ou des rebase tordus il est toujours possible de revenir en arrière, à moins d’avoir fait “git gc” dont le but est de nettoyer le repo.









cosmocat a écrit :



Pas tout le temps…

Pour construire un commit, je préfère largement une IHM à la ligne de commande. Surtout pour ajouter des parties de fichiers.





+1, c’est le seul cas où je conseille à mes collègues de passer par une IHM, pour voir le diff, se relire une ultime fois, et eventuellement committer ligne par ligne.







D’ailleurs, est-ce que cette mouture permettra de committer ligne par ligne comme git gui ou cola ?

Parce que bon, ça manque beaucoup ça.









gokudomatic a écrit :



Pour bosser sérieusement, c’est ligne de commande et point barre.





Les vrais développeurs rentrent des cartes perforées.









wagaf a écrit :



Il semble qu’encore aujourd’hui tu n’a pas saisi grand chose au fonctionnement de Git, pas une seule de tes affirmations n’est juste <img data-src=" /> Mais en effet quand on appréhende l’outil comme si c’était CVS sans connaître le fonctionnement des branches, tags etc. on est vite perdu, ce n’est pas une critique.



Il est quasi impossible de perdre des données avec Git, même après un reset Hard ou des rebase tordus il est toujours possible de revenir en arrière, à moins d’avoir fait “git gc” dont le but est de nettoyer le repo.







Perso j’utilise svn au quotidien et à une époque je bossais aussi sur Clearcase et je n’ai jamais eu de soucis particuliers, même avec des branches, des tags et des externals un peu tordus. A une époque j’avais envisagé de tester Hg mais visiblement il n’est “plus à la mode”, tout le monde passe sur Git même pour un projet perso ou avec 2 collaborateurs …



Concernant la perte de données je ne saurais dire, juste un jour que j’ai voulu récup des maj d’un autre et j’ai jamais pu récupérer mes sources derrière, impossible de comprendre ce qu’il fallait faire et “l’expert” a séché en disant “ben t’es niqué t’as tout perdu, fallait pas faire comme ça”.



Depuis quand je veux merge sur un dépot Git j’utilise un truc atroce, je merge à la main sur un repo propre et ensuite j’écrase … (et je vous parlerai même pas de comment je fais pour nettoyer un fork, y’a des âmes sensibles ici <img data-src=" /> )









wagaf a écrit :



Il semble qu’encore aujourd’hui tu n’a pas saisi grand chose au fonctionnement de Git, pas une seule de tes affirmations n’est juste <img data-src=" /> Mais en effet quand on appréhende l’outil comme si c’était CVS sans connaître le fonctionnement des branches, tags etc. on est vite perdu, ce n’est pas une critique.



Il est quasi impossible de perdre des données avec Git, même après un reset Hard ou des rebase tordus il est toujours possible de revenir en arrière, à moins d’avoir fait “git gc” dont le but est de nettoyer le repo.







Tiens, j’allais écrire exactement ce commentaires ;)

donc +1000









wagaf a écrit :



Sourcetree pas dispo pour linux…







C’est assez paradoxal mais Linux est la plateforme avec aucune IHM git descente…



Bien que débutant avec Git, je n’utilise pas l’UI de GitHub for Windows. En revanche j’utilise beaucoup le shell fourni avec : posh-git, qui fonctionne sous PowerShell, et qui est vraiment bien foutu. Je conseille d’ailleurs d’installer vim pour aller avec (oui oui, vim pour Windows…)








BabyAzerty a écrit :



Oui, il parait que les vrais développeurs utilisent la ligne de commande uniquement. Il parait aussi que ceux qui ne le font pas sont systématiquement des sous-races.





C’est un préjugé relayé par des ignorants. La vérité est que ceux qui n’utilisent pas la ligne de commande sont en fait des sous-classes.<img data-src=" />









tom103 a écrit :



Bien que débutant avec Git, je n’utilise pas l’UI de GitHub for Windows. En revanche j’utilise beaucoup le shell fourni avec : posh-git, qui fonctionne sous PowerShell, et qui est vraiment bien foutu. Je conseille d’ailleurs d’installer vim pour aller avec (oui oui, vim pour Windows…)





Vim… Ligne de commande…



Arrêtez les gars, passez en 2014. Adoptez un vrai IDE avec refactorisation, navigations rapides, auto-complétion et tout le toutim, et un programme qui vous permet de vérifier facilement vos changements et les éventuels conflits avant de basculer (commiter) sur le repo. Ça fera plaisir à vos collègues.









HarmattanBlow a écrit :



Vim… Ligne de commande…



Arrêtez les gars, passez en 2014. Adoptez un vrai IDE avec refactorisation, navigations rapides, auto-complétion et tout le toutim, et un programme qui vous permet de vérifier facilement vos changements et les éventuels conflits avant de basculer (commiter) sur le repo. Ça fera plaisir à vos collègues.





lol! Je crois qu’il y a confusion, les gars. Pour ma part, en tous cas, je ne parlais de ligne de commande que pour git. Je ne fais pas tout en ligne de commande.<img data-src=" />









cosmocat a écrit :



C’est assez paradoxal mais Linux est la plateforme avec aucune IHM git descente…





Je citais justement SmartGit en commentaire #2 <img data-src=" />









HarmattanBlow a écrit :



Vim… Ligne de commande…



Arrêtez les gars, passez en 2014. Adoptez un vrai IDE avec refactorisation, navigations rapides, auto-complétion et tout le toutim, et un programme qui vous permet de vérifier facilement vos changements et les éventuels conflits avant de basculer (commiter) sur le repo. Ça fera plaisir à vos collègues.







Beatnik <img data-src=" />









wagaf a écrit :



Je citais justement SmartGit en commentaire #2 <img data-src=" />







Merci, j’y jetterais un coup d’oeil, c’est vrai que la plupart des outils testés sous Linux sont instables (GitG…) et vraiment pas ergonomiques.

Mais bon “grâce” à eux, je me suis habitué au terminal pour les commit :) .



Faudra que je me repenche sur la configuration de Git Server sur un Synology. Actuellement, c’est SVN qui est vraiment simple à mettre en place et que j’ai adopté car j’ai pas actuellement besoin de plus, et qu’au pire c’est simple de migrer vers autre chose.



Et je commit très bien depuis mon éditeur avec un :!svn ci -m “Message de commit” <img data-src=" />


Personnelement je priviligie la ligne de commande pour git, parcequ’en ligne de commande quand tu veux faire un truc, il faut te documenter et comprendre comment ca marche avant de le faire, alors que dans un cliquodrome tu cliques et fais n’importe quoi avant de te renseigner en espérant que ca marche.

Aprés une fois que la ligne de commande est maitrisée ca peut etre interessant dans certain cas d’utiliser une sur couche graphique, perso je n’utilise que gitk pour regarder les diff (aussi si quelqu’un apprend à coder je lui dirait d’utiliser emacs et de compiler en ligne de commande avant d’utiliser un ide, ca nous force à comprendre tellement de chose fondamentale pour la programation).



Aprés pour comparer les scm, pour avoir utilisé git, hg, p4, svn et csv. Je prefère de loin git (mais c’est celui que je connais le mieux aussi, et hg est assez proche de git). Git peut etre utiliser comme logiciel de versionnage local, comme logiciel de sauvegarde du travail avec historique, et comme pur scm, et en plus il scale super bien. La seul chose qui lui manque (peut etre que ca existe dans les dernière versions) c’est une gestion des droits.








Funigtor a écrit :



Actuellement, c’est SVN qui est vraiment simple à mettre en place et que j’ai adopté car j’ai pas actuellement besoin de plus, et qu’au pire c’est simple de migrer vers autre chose.







Pour moi, c’est plus la description de git, çà….

Pas besoin de serveur. Un répertoire partagé si besoin.

Et git est maintenant le couteau suisse des vcs avec une possibilité de migrer depuis TOUS les vcs!









cosmocat a écrit :



Pour moi, c’est plus la description de git, çà….

Pas besoin de serveur. Un répertoire partagé si besoin.





Et si je me lance dans un développement à plusieurs je peux donner une url pour que mes amis n’aient plus qu’à faire un git clone git:/// ? Et des droits de push ? Sans devoir leur créer des comptes utilisateurs sur mon NAS ?



En l’occurence, avec svn j’ai juste à donner un username et un mot de passe et on peut faire un checkout directement (Et commiter si je donne le droit)



Sachant qu’au pire il reste toujours git-svn si vraiment on est limité.



J’ai toujours du mal à comprendre mais ce client a vraiment un gros défaut je trouve.



Il ne gère tout simplement pas les conflits de fusions. 2 devs bossant séparément font des commits en local destinés à être envoyés sur un dépôt centralisé, si l’un des deux à le malheur d’avoir fait une modif au même endroit que l’autre, le push de la 2ème personne va s’arrêter avec un message d’erreur qui dit en substance: “Non”.



A l’école on a du utiliser Github pour des projets, plein de potes ont installé le client “officiel” et au final ils ont tous ragé dessus; tous les jours on entendait des “Git c’est vraiment de la merde.”



Je trouve ca vraiment bizarre pour un client qui semble miser sur la simplicité et la facilité d’utilisation, de par l’interface soignée, très Métro. Or un débutant qui voit son push échouer sans message pour lui expliquer pourquoi ni ce qu’il pourrait faire, c’est juste hyper frustrant.



Je recommande GitExtensions perso.








Funigtor a écrit :



Et si je me lance dans un développement à plusieurs je peux donner une url pour que mes amis n’aient plus qu’à faire un git clone git:/// ? Et des droits de push ? Sans devoir leur créer des comptes utilisateurs sur mon NAS ?



En l’occurence, avec svn j’ai juste à donner un username et un mot de passe et on peut faire un checkout directement (Et commiter si je donne le droit)



Sachant qu’au pire il reste toujours git-svn si vraiment on est limité.





Pour un petit setup comme tu décris regarde du côté de gitolite.



Les droits et repos sont gérés assez simplement dans un repo git “d’admin” incluant un fichier de config et un dossier avec les clefs publiques. Pour ajouter des repos ou des contributeurs, il suffit de pusher un commit sur ce repo. Un seul utilisateur à configurer (“git”), et repos accessibles à l’url git@tonserveur:nomdurepo



Pour les setup plus évolués il y a Gerrit, créé par Google pour le dev d’Android, très puissant mais plus complexe <img data-src=" />









wagaf a écrit :



Pour un petit setup comme tu décris regarde du côté de gitolite.



Les droits et repos sont gérés assez simplement dans un repo git “d’admin” incluant un fichier de config et un dossier avec les clefs publiques. Pour ajouter des repos ou des contributeurs, il suffit de pusher un commit sur ce repo.





Intéressant, je bookmark ça.









Tkop a écrit :



Personnelement je priviligie la ligne de commande pour git, parcequ’en ligne de commande quand tu veux faire un truc, il faut te documenter et comprendre comment ca marche avant de le faire, alors que dans un cliquodrome tu cliques et fais n’importe quoi avant de te renseigner en espérant que ca marche.







Pourquoi apprendre en ligne de commande permettra réellement de comprendre, parce qu’on en aura bavé ? Je suis dubitatif face à la technique, je connais au moins 3 autres devs qui “copient-collent” les commandes aveuglément et qui recommandent de pas faire autrement parce que sinon “tu vas tout péter”, en quoi ça permet d’apprendre comment ça marche par rapport à un GUI ?



J’avoue que j’ai vraiment du mal avec cette approche, particulièrement présente dans le domaine de l’open source. Les outils doivent servir à faciliter le boulot du développeur, pas l’inverse. Si faire des opérations à priori simples (comme versionner un fichier ou mettre à jour) demande un effort intellectuel important parce qu’il faut se taper toute une toolchain opaque qui elle-meme fait appel à un workflow opaque, où est l’aide apportée ? Est ce que la puissance et la scabilité ont forcément ce prix ?









HarmattanBlow a écrit :



Vim… Ligne de commande…



Arrêtez les gars, passez en 2014. Adoptez un vrai IDE avec refactorisation, navigations rapides, auto-complétion et tout le toutim, et un programme qui vous permet de vérifier facilement vos changements et les éventuels conflits avant de basculer (commiter) sur le repo. Ça fera plaisir à vos collègues.







Tu m’as mal compris… je n’utilise pas vim pour coder bien sûr ; j’utilise Visual Studio 2013 avec des plugins comme ReSharper, dont j’aurais d’ailleurs du mal à me passer. J’utilise la ligne de commande presque exclusivement pour Git, et vim me sert principalement à éditer les messages de commit, faire des rebase interactifs, etc. Ca me sert aussi parfois à faire une petite modif rapide sur un fichier, c’est plus rapide que d’ouvrir un IDE ou même un éditeur de texte graphique.



Mais tu aurais tort de mépriser la ligne de commande, c’est un outil très puissant et très productif. Les utilisateurs Windows n’ont généralement pas la “culture” ligne de commande, parce que la console de Windows est nulle à ch* comparée à ce qui existe sous Unix/Linux/OSX (bash, zsh, etc). PowerShell constitue déjà un gros pas en avant ; la syntaxe est un peu bizarre au premier abord, mais ça permet de faire à peu près n’importe quoi.



Quant à vim, ça peut sembler rétro, mais c’est vraiment un bon éditeur, une fois que tu as appris à l’utiliser… et il a l’avantage de ne pas morphaler les ressources comme Visual Studio ou Eclipse. Evidemment, ce n’est pas aussi riche en fonctionnalités (c’est pourquoi je ne l’utilise pas pour coder), mais si tu veux juste éditer rapidement un fichier texte, c’est parfait. Et d’ailleurs il y a plein de développeurs qui l’utilisent aussi pour coder…









gokudomatic a écrit :



lol! Je crois qu’il y a confusion, les gars. Pour ma part, en tous cas, je ne parlais de ligne de commande que pour git. Je ne fais pas tout en ligne de commande.<img data-src=" />







SourceTree + Ligne de commande = Ultimate combo :-)



Et TortoiseGit ? Personne n’en parle, je le trouve pratique pourtant :

https://code.google.com/p/tortoisegit/



Basé sur :

http://tortoisesvn.net/








garvek a écrit :



Pourquoi apprendre en ligne de commande permettra réellement de comprendre, parce qu’on en aura bavé ? Je suis dubitatif face à la technique, je connais au moins 3 autres devs qui “copient-collent” les commandes aveuglément et qui recommandent de pas faire autrement parce que sinon “tu vas tout péter”, en quoi ça permet d’apprendre comment ça marche par rapport à un GUI ?



J’avoue que j’ai vraiment du mal avec cette approche, particulièrement présente dans le domaine de l’open source. Les outils doivent servir à faciliter le boulot du développeur, pas l’inverse. Si faire des opérations à priori simples (comme versionner un fichier ou mettre à jour) demande un effort intellectuel important parce qu’il faut se taper toute une toolchain opaque qui elle-meme fait appel à un workflow opaque, où est l’aide apportée ? Est ce que la puissance et la scabilité ont forcément ce prix ?







Dans le cas de git les lignes de commandes sont excellente et suivent un workflow logique. enchaîner les lignes de commandes permet de comprendre le workflow et l’utilité de chaque action. De plus la ligne de commande offrent un panel d’options très étendu qui permet d’aller bien plus vite qu’une GUI sur certains scénario.

Connaitre la ligne de commande permet également de l’utiliser sur un serveur, sur tout OS ou encore de l’associer git à des gestionnaire de tâche tel que Grunt ou Gulp.



Mais comme dit plus haut je suppose que c’est un point de vue windowsien, je suis d’accord c’est pas mal une gui dans un IDE, mais ça apporte une couche d’abstraction et un peu trop de “magie” pour comprendre ce qu’il se passe









garvek a écrit :



Pourquoi apprendre en ligne de commande permettra réellement de comprendre, parce qu’on en aura bavé ? Je suis dubitatif face à la technique, je connais au moins 3 autres devs qui “copient-collent” les commandes aveuglément et qui recommandent de pas faire autrement parce que sinon “tu vas tout péter”, en quoi ça permet d’apprendre comment ça marche par rapport à un GUI ?



J’avoue que j’ai vraiment du mal avec cette approche, particulièrement présente dans le domaine de l’open source. Les outils doivent servir à faciliter le boulot du développeur, pas l’inverse. Si faire des opérations à priori simples (comme versionner un fichier ou mettre à jour) demande un effort intellectuel important parce qu’il faut se taper toute une toolchain opaque qui elle-meme fait appel à un workflow opaque, où est l’aide apportée ? Est ce que la puissance et la scabilité ont forcément ce prix ?







C’est vrai que c’est tellement mieux d’utiliser un outils sans savoir comment on doit le faire, sur tout professionnellement. C’est tellement répandu dans le mode du développement que ça en est devenue la norme ….









tom103 a écrit :



Mais tu aurais tort de mépriser la ligne de commande, c’est un outil très puissant et très productif. Les utilisateurs Windows n’ont généralement pas la “culture” ligne de commande, parce que la console de Windows est nulle à ch* comparée à ce qui existe sous Unix/Linux/OSX (bash, zsh, etc). PowerShell constitue déjà un gros pas en avant ; la syntaxe est un peu bizarre au premier abord, mais ça permet de faire à peu près n’importe quoi.





J’ai quand même une dizaine d’années d’expérience sur des nix, hein ? Et tout ça bien avant les UI user-friendly d’aujourd’hui. ;)



Et quant à la ligne de commandes, non ce n’est pas un outil très puissant. J’aimerais certes en avoir une (et, oui, la ligne de commande sous Windows, y compris Powershell, est exaspérante) mais je la réserverais aux tâches qui ne gagnent rien à avoir une UI et simplement parce qu’il est plus rapide de taper deux mots que d’ouvrir une fenêtre.



Or les outils de contrôle de version gagnent grandement à bénéficier d’un UI, ne serait-ce que pour un contrôle et un examen rapide des fichiers modifiés avant le commit ou la recherche .







Tkop a écrit :



C’est vrai que c’est tellement mieux d’utiliser un outils sans savoir comment on doit le faire, sur tout professionnellement. C’est tellement répandu dans le mode du développement que ça en est devenue la norme ….





Parce qu’apprendre les pelletées d’options textuelles de Git t’enseigne le fonctionne interne des algorithmes de Git ?



La seule chose que t’enseigne la ligne de commandes, c’est la ligne de commandes.









HarmattanBlow a écrit :



La seule chose que t’enseigne la ligne de commandes, c’est la ligne de commandes.





Heureusement que la ligne de commande ne sert pas à l’enseignement mais à la productivité.









HarmattanBlow a écrit :



Parce qu’apprendre les pelletées d’options textuelles de Git t’enseigne le fonctionne interne des algorithmes de Git ?



La seule chose que t’enseigne la ligne de commandes, c’est la ligne de commandes.







C’est pas ce que j’ai dis, je critique le fait d’utiliser un programme sans savoir comment il faut l’utiliser, je m’en fiche aussi de comment ca fonctionne en interne. Ce qui est important c’est de connaitre son fonctionnement









HarmattanBlow a écrit :



J’ai quand même une dizaine d’années d’expérience sur des nix, hein ? Et tout ça bien avant les UI user-friendly d’aujourd’hui. ;)



Et quant à la ligne de commandes, non ce n’est pas un outil très puissant. J’aimerais certes en avoir une (et, oui, la ligne de commande sous Windows, y compris Powershell, est exaspérante) mais je la réserverais aux tâches qui ne gagnent rien à avoir une UI et simplement parce qu’il est plus rapide de taper deux mots que d’ouvrir une fenêtre.



Or les outils de contrôle de version gagnent grandement à bénéficier d’un UI, ne serait-ce que pour un contrôle et un examen rapide des fichiers modifiés avant le commit ou la recherche .





Parce qu’apprendre les pelletées d’options textuelles de Git t’enseigne le fonctionne interne des algorithmes de Git ?



La seule chose que t’enseigne la ligne de commandes, c’est la ligne de commandes.







Merci ! Un qui me comprend ! <img data-src=" />



(Note: j’utilise les script quotidiennement et côté programmes obscurs j’ai déjà fort à faire avec les outils internes au travail, donc si on doit en plus en rajouter une couche avec les outils externes … on a pas fini)







petogo a écrit :



Dans le cas de git les lignes de commandes sont excellente et suivent un workflow logique. enchaîner les lignes de commandes permet de comprendre le workflow et l’utilité de chaque action. De plus la ligne de commande offrent un panel d’options très étendu qui permet d’aller bien plus vite qu’une GUI sur certains scénario.

Connaitre la ligne de commande permet également de l’utiliser sur un serveur, sur tout OS ou encore de l’associer git à des gestionnaire de tâche tel que Grunt ou Gulp.



Mais comme dit plus haut je suppose que c’est un point de vue windowsien, je suis d’accord c’est pas mal une gui dans un IDE, mais ça apporte une couche d’abstraction et un peu trop de “magie” pour comprendre ce qu’il se passe







Merci pour cette explication, je comprends le point de vue.



Comme je vois beaucoup de troll anti UI alors je lance qqs un aussi …



Les pros ligne de commandes sont des primates qui ont peur d’évoluer.

Ou les pros ligne de commandes sont des conservateurs d’une secte qui craignent le progrès car c’est mauvais pour leur business.

Etc …



Dans tous les cas personnellement je choisis toujours l’outil le plus pratique et le moins prise de tête. Que ce soit ligne de commandes ou UI. J’ai d’autres chats à fouetter que d’être sectaire ^^








garvek a écrit :



Merci ! Un qui me comprend ! <img data-src=" />



(Note: j’utilise les script quotidiennement et côté programmes obscurs j’ai déjà fort à faire avec les outils internes au travail, donc si on doit en plus en rajouter une couche avec les outils externes … on a pas fini)





En gros tu veux migrer sur un nouvel outil sans avoir a apprendre comment il fonctionne ? Soit tu reste sur ce que tu connais soit tu prends le temps de voir comment ça fonctionne.



Git n’est pas forcement complique une fois que tu connais les commandes de base. Et te permet de faire pas mal de choses. Bref un excellent outil très puissant.



Pour les utilisateurs d’Emacs, je conseil fortement l’excellentissime Magit:http://magit.github.io/








seb2411 a écrit :



En gros tu veux migrer sur un nouvel outil sans avoir a apprendre comment il fonctionne ? Soit tu reste sur ce que tu connais soit tu prends le temps de voir comment ça fonctionne.



Git n’est pas forcement complique une fois que tu connais les commandes de base. Et te permet de faire pas mal de choses. Bref un excellent outil très puissant.







Nope, je cherche à éviter de me prendre la tête “inutilement”. Les DVCS et VCS ne sont vraiment pas simples pour passer de l’un à l’autre car ils encouragent un mode de fonctionnement trop différent; mais en plus de ça Git rajoute une surcouche de complexité – et c’est cette dernière que je reproche, pas la première (par ex j’ai moins de problèmes avec Mercurial).









garvek a écrit :



Nope, je cherche à éviter de me prendre la tête “inutilement”. Les DVCS et VCS ne sont vraiment pas simples pour passer de l’un à l’autre car ils encouragent un mode de fonctionnement trop différent; mais en plus de ça Git rajoute une surcouche de complexité – et c’est cette dernière que je reproche, pas la première (par ex j’ai moins de problèmes avec Mercurial).





Tu as des soucis a quel niveau avec GIT par rapport a Mercurial ?









petogo a écrit :



Dans le cas de git les lignes de commandes sont excellente et suivent un workflow logique.





<img data-src=" />









seb2411 a écrit :



Tu as des soucis a quel niveau avec GIT par rapport a Mercurial ?







Le nom des commandes, le nombre astronomiques d’options et dont l’usage n’est pas clair, le fait qu’il n’y aie pas de process vraiment défini pour la gconf (bien que ce côté ça puisse se compenser en ayant recours à des workflow copiés-collés sur Internet, mais là encore c’est pas dit que l’on comprenne vraiment au final l’usage). Et la numérotation en hachage (mais c’est mineur, on va dire que c’est aussi chiant que le passage à l’IPv6).