Attendue depuis quelques temps, la nouvelle version de GitHub Desktop est disponible pour OS X et Windows. Au programme, quelques améliorations, notamment au niveau de l'ergonomie et de l'interface.
La phase de test est terminée, GitHub Desktop 3.0 est disponible. Après de premières moutures qui restaient assez basiques, l'équipe a surtout voulu revoir l'ergonomie de son outil, le rendre plus utile et plus pratique au quotidien. Ainsi, vous pouvez désormais visualiser plus directement les branches d'un dépôt, les comparer, et effectuer une sélection de manière plus naturelle que précédemment. Le tout depuis la vue principale.
Vous pouvez tout aussi facilement passer d'un commit à un autre, sélectionner seulement certains fichiers ou certaines lignes pour composer un commit puis directement effectuer un pull request. Le reste sera plus ou moins identique aux moutures 2.x. Le tout pèsera un peu plus de 100 Mo.
- Télécharger GitHub Desktop 3.0 (OS X et Windows)
Commentaires (83)
#1
Toujours pas de version Linux prévue ?
#2
Ça sert à quoi une GUI pour git ?
#3
#4
Haha, on croirait entendre mes collègues.
Pour certains projets avec des tas d’assets qui sont sur git (du style jeu vidéo) une GUI ça permet de rapidement voir ce qui a été modifié. Je trouve aussi la que la visualisation des diff est bien plus pratique avec un outil dédié qu’avec git diff ou un éditeur de base (bien que bcp d’IDE sachent bien le faire).
Et quand y a des profils moins “dev” dans l’équipe, du style graphistes, qui doivent commit et push des assets, c’est aussi vachement pratique …
#5
Oui. Si ça permet aux profanes de mettre un doigt dans le cambouis de temps en temps pour les bouts qui les concernent, c’est cool.
Sinon pour un vrai dev, non. Ça va tant qu’il est sur desktop, mais s’il doit utiliser Git sur un serveur headless, il sera perdu.
#6
#7
Le meilleur pour moi est SmartGit http://www.syntevo.com/smartgit/
Hélas non libre, mais tellement efficace…
#8
#9
#10
#11
J’utilise git gui au moment de chaque push, histoire de refaire un tour sur ce que je veux commit et vérifier que je n’ai rien oublié (commentaire/log en trop, etc..) idem si je veux revert un commit en local, c’est facile.
Pour les pull request, je fait ça depuis github directement.
Ça suffit comme consigne en interne pour que les différents profils évitent les conneries;)
#12
likelikelikelikelikelike
#13
Sinon git log –oneline –abbrev-commit –all –graph –decorate –color.
#14
#15
Pour ceux qui dev de vrais projects avec plus de 1000 fichiers, pas de simple flappy-bird clone ;)
#16
#17
#18
C’est pourtant tellement plus simple de parser la sortie d’un git status ou autre à coups de grep, sed et compagnie que de chercher pendant de longues minutes dans la liste d’une interface graphique ce qui t’intéresse…
#19
Et Framagit, pourquoi personne n’en parle
" />
#20
Ceci. Tellement vrais.
J’utilisais git en graphique avant. Et puis, nouveau boulot, nouvelles pratiques: bash! Eh bah j’y retournerai pas, à cette interface.
Bon, c’est vrais que le site de github propose des trucs cools, genre pour les PR et les releases.
#21
Je ne dis pas que les interface graphiques sont le mal, clairement. Mais l’exemple de @Naneday était asse mal choisi pour le coup !
#22
Ceux-là s’en sortent très bien aussi, merci bien! ;)
Cela dit, si j’avais à bosser sous Windows, j’imagine que j’irais plus naturellement vers une GUI.
#23
Autant moi je n’arrive pas à utiliser une GUI pour Git (j’aime bien la ligne de commande pour quelques trucs), que ce soit SmartGit, Gitg, Gitk, et j’en passe.
Autant, que Github passe à silence Linux, gros WTF… Ils pourraient presque prendre GitG, nouvelle branche, 2-3 et tweaks d’interface, et tout le monde est content. Ou bien un port wine.
Ah et sinon, mon alias git graph :
git log –graph –pretty=format:‘%C(auto)%h - %C(bold cyan)%an %C(bold green)(%ar)%C(bold yellow)%d%n” %C(bold red)%s%C(reset)%n”%w(0,14,14)%b’
#24
“De vrais projets de plus de 1000 fichiers”
Maaaaiiiiiiiiis oui… Parce qu’on ne sert à rien si on ne travaille pas sur un très très gros projet très illisible ?
#25
cmder ou git bash font largement l’affaire.
Ceci dit, même si je privilégie largement la ligne de commande, avoir une GUI pour Git peut parfois etre pratique. Par exemple si tu travaille avec git-flow et SourceTree, c’est pas mal quand dans l’equipe il n’y apas que de dev qui joue de la ligne de commande toute la journée.
#26
#27
Non brazynoma, il faut respecter ces gens qui pensent qu’il n’y qu’une seule bonne façon de faire les choses. Ce sont de grands visionnaires ! 
" />
#28
#29
#30
À voir si cette nouvelle version est aussi complète que SourceTree, l’ancienne version était jolie et simple mais il manquait pas mal de fonctionnalités pénible à faire en ligne de commande.
#31
#32
Plus fermé que ça tu meurs. Well done.
#33
#34
#35
#36
Quel homme, taper de si belle lignes de commande, j’en ai le kiki tout dur. Ces pauvres mâles béta avec leur GUI ne tiennent pas la comparaison une seconde.
" />
" />
" />
Manquerai plus qu’une petite regex et ce serait l’orgasme.
#37
J’ai plus souvent vu des GUI foutrent le bordel dans un repo que des lignes de commandes. Avec un GUI tu maitrise pas vraiment ce qui est fait alors qu’en ligne de commande pas de soucis.
#38
Marrant. Git a été conçu pour avoir un système complètement décentralisé où chacun a sa propre version/évolution du code… et au final ca converge lentement vers un système classique avec un “master” central, des branches/forks et des checkout/merge en local, puis des checkin vers le master.
Tout comme le P2P s’en retourne vers le DDL, le Git retourve au cvs/svn.
#39
En GUI, rien ne battra à mon sens GitExtensions sous windows : quasi tout est dispo, et les commandes sont toujours affichées donc au fur et à mesure, tu l’utilises de moins en moins.
Après faut pas déconner, quand t’as plusieurs commit à pusher sur pas mal de fichier, la GUI apporte un plus. Idem quand tu ne veux commiter que certaines lignes modifiées d’un fichier, ou visualiser le log quand tu travailles avec beaucoup de branches. Et pour tous le reste, y’a la cli, qui déboîte.
Chacun l’utilise comme il l’entend et comme il lui convient mais faut arrêter avec les rageux du style “la ligne de commande c’est un truc de retardé” et “les GUI sont là pour les noobs” & cie. C’est tout sauf constructif, collaboratif et maléable. Bref, anti git en somme :)
@yellowiscool SourceTree n’arrive pas à la cheville de GitExtensions (qui au passage semble tourner sous linux et mac). Réellement ;)
#40
#41
#42
Mouais, ça va pas me faire quitter Magit tout ça.
——————————————————————
#43
30 ans après l’avènement de l’Amiga, les développeurs du libre découvrent toute la puissance d’une interface graphique.
" />
Champagne !
#44
#45
De l’utilisation que j’en ai, le coté décentralisé de git permet de chacun pouvoir bosser tranquille de son coté. Mais quand on veut une vue d’ensemble sur le projet, on a naturellement tendance à avoir un point centralisé pour mettre ce qui est (théoriquement) à peu près au point.
" />
Alors effectivement, git a tendance à revenir vers le centralisé, mais je connais des personnes qui font des recherches sur le travail collaboratif décentralisé, donc qui c’est, on trouvera peut-être mieux que la tendance actuelle.
#46
#47
#48
Aucun rapport
#49
#50
Je code depuis le ST et l’Amiga et j’ai jamais accroché ces solutions.
L’impression d’un manque de contrôle notoire entre les versions. Un mal à l’aise permanent ou tu dois polus retenir dans quoi tu es que d’y réfléchir. Processus de production (rendu) du livrable encore pas clair (d’une solution a l’autre). Puisqu’il y a des Guru du Fork autoproclamé ou pas voici ma question
Ce que je cherche :
Que le meilleur gagne.
Merci bien.
#51
Visiblement le setup launcher download fourni GitHubSetup.exe ne gère pas les proxy ?
#52
#53
Rhaaa, je me lève et j’apprends que je ne suis pas un vrai informaticien vu que je n’utilise pas la ligne de commande et que j’ai horreur de ce concept des années 70… VDM
#54
Git ne permet pas tous ça ?
J’ai surement pas bien compris ce que tu demandais mais j’ai répondu ce qui me semblais adapté.
#55
#56
#57
#58
#59
#60
@Mahn & @127.0.0.1
Le 100% local c’est pour des questions de sécurité/confidentialité. Je ne dénigre pas la solution Github qui convient pour les gens séparés par des distances ou des océans. Toutefois il y a des contraintes parfois.
Effectivement on s’adapte mais parfois j’ai pas l’impression que c’est possible. Donc plutôt que de galérer à installer, importer son projet et tester / étudier tous les détails des solutions, c’est quand même bien de pouvoir avoir un vrai panel d’avis et qu’on puisse nous dire si ça colle ou pas avec ce que l’on veut. C’est un peu le désert partout. C’est presque une secte “des gens maitrisant les CVS vs les autres”.
Je trouve qu’au niveau IDE c’est resté au ras des pâquerettes. Généralement on se trouve un éditeur qui est capable et encore développé; on se fait un thème et puis on ‘roule’ comme cela. Effectivement Atom pourrait convenir aussi, s’il on peut bien entendu le customiser sévèrement. Quoiqu’il en soit ça manque d’info et de fonctionnalité quand on aborde le thème du versionning en général.
#61
Ben je n’ai pas parler du dépôt basique parce que je trouve l’intérêt limité, surtout que vu ces exigence je ne pense pas qu’il s’en serve pour conserver l’historique de quelques fichiers de configuration. ^^
D’autant que pour le déploiement :/
Si tu t’amuse a générer un zip pour le mettre sur le serveur, tu perd encore en fonctionnalité de git.
#62
ha pardon j’ai dit github ? je pensais gitlab :/
Et oui atom, c’est … comment dire … un couteau suisse ;)
#63
#64
#65
PCI devrait abandonner cet éditeur bbcode de caca et passer à Markdown.
" />
#66
Y’a des moments c’est vrais que ça pêche un peu.
#67
Pour le pack.
Admettons que je dois produire un pack complet de fichier à livrer. (Que ça soit un programme ou un web on s’en fout) Il me faut donc produire la version qui m’intéresse précisément pour pouvoir la livrer. Donc eventuellement la branche spécifique. En gros faire marcher la moulinette a créer les fichiers a volonté.
#68
#69
#70
#71
Si tu fais une faute de frappe la commande passe pas. Si tu clique a coté par contre…, de plus trop souvent les GUI font des commandes en plus que tu ne maitrise pas réellement.
#72
C’est un peu à géométrie variable si tu prefères.
Autant je serais choqué qu’un dev ne sache pas se servir de git à la ligne de commande tout en prétendant être au top, autant je comprend qu’un graphiste soit vite frustré par un outil uniquement à la cli, parce que “c’est comme ça qu’il faut faire”.
Mon chef est un tueur avec vim, mais une quiche avec Photoshop.
Mon graphiste est bon en toshop, illustrator et cie, mais prefere un outil graphique pour utiliser git.
ça ne me parait pas illogique.
#73
+100000
C’est de plus en plus énervant… et je suis prêt à parier que beaucoup commente moins voire plus du tout à cause de ce truc vraiment mal fini. Pas glop !
#74
ok mais y’a quoi d’autre comme solution? Bon le classique CVS mais après ?
#75
Je t’ai donner mon cas avec les script gitlab parce que je le sais fonctionnel et que c’était notre besoin. Vous avez pas une équipe technique en charge de la gestion serveur/déploiement ? Parce qu’il y as un peu de boulot pour avoir un truc qui correspondra a ce que vous voulez.
#76
Quand je-vous parlais-parlera de solution je pensai-pensera de produits (moment culture).
Je pense que ce n’est pas un nombre de serveur qui est requis. De l’ergonomie / flexibilité serai plus fun. Après tout c’est le but.
#77
#78
Je ne parlais pas en nombre de serveur juste t’adresser à un service technique avec qui tu travaille probablement déjà. Pour moi la solution c’est gitlab avec ces fonctionnalités.
Quand je parlais d’un “peu de boulot” je parlais niveau configuration pour que vos besoin sois respecté.
Merci pour le lien, tu ne pouvais pas mieux tomber je suis en train de regarder ça :http://www.imdb.com/title/tt0076929/
#79
#80
#81
Comme ca dès que le seul truc que tu as a disposition c’est une connexion ssh tu es même pas capable de faire un simple push ou checkout…
#82
#83