GitHub Desktop 3.0 est là, avec une visualisation graphique des branches

seb2411

Le 12/08/2015 à 15h52

Toujours pas de version Linux prévue ?

Nikodym

Le 12/08/2015 à 15h53

Ça sert à quoi une GUI pour git ?

marba

Le 12/08/2015 à 15h59

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

À ce que les amateurs viennent pourrir les projets de passionnés…

RDeluxe

Le 12/08/2015 à 16h02

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 …

ColinMaudry Abonné

Le 12/08/2015 à 16h06

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.

Oxynux

Le 12/08/2015 à 16h06

seb2411 a écrit :

Toujours pas de version Linux prévue ?

Malheureusement :‘(

wagaf Abonné

Le 12/08/2015 à 16h13

Le meilleur pour moi est SmartGit http://www.syntevo.com/smartgit/

Hélas non libre, mais tellement efficace…

XalG

Le 12/08/2015 à 16h13

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

Déjà qu’ils nous ont fait chr il y a 30 ans pour avoir des fenêtres…

zefling Abonné

Le 12/08/2015 à 16h17

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

Perso, je passe par NetBean qui gère git en interface graphique. Je vois pas pourquoi j’irais me faire chier avec les lignes de commandes (sous Linux " />).

Yangzebul

Le 12/08/2015 à 16h22

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

" />

Arnaud3013

Le 12/08/2015 à 16h25

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;)

anonyme_ddd683d8db7fcb953c6bcd5d184abb16

Le 12/08/2015 à 16h36

likelikelikelikelikelike 

Antwan

Le 12/08/2015 à 16h44

Sinon git log –oneline –abbrev-commit –all –graph –decorate –color.

mahn

Le 13/08/2015 à 21h44

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/

Nikodym

Le 14/08/2015 à 13h10

lossendae a écrit :

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.

Je ne pensais pas que des non initiés viendraient y mettre les mains (en lecture seule alors ? " />), je suis entouré de barbus.

catseye

Le 14/08/2015 à 23h41

Krogoth a écrit :

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.

C’est bien là l’avantage justement t’as pas besoin de savoir ce que ça génère comme commande … c’est un système d’interfaces conceptuelles basées sur les usages ‘normaux’ et non une interface programmatique (comme le command line).

Un développeur ne devrait jamais à avoir à s’inquiéter des commandes internes, mais simplement savoir comment faire un check-in ou commit, check-out ou update, branch, merge … etc etc …. les détails internes n’ont aucun intérêt et surtout en utilisant les concepts plutôt que les commandes, tu peux passer de sourcesafe à svn, à Mercurial, à git, à TFS, à Starteam, à n’importe quoi … sans jamais connaitre quoi que ce soit de la technologie en arrière (dont un développeur n’a strictement rien à foutre).

Krogoth

Le 15/08/2015 à 20h19

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…

pomme31

Le 18/08/2015 à 10h08

catseye a écrit :

C’est bien là l’avantage justement t’as pas besoin de savoir ce que ça génère comme commande … c’est un système d’interfaces conceptuelles basées sur les usages ‘normaux’ et non une interface programmatique (comme le command line).

Un développeur ne devrait jamais à avoir à s’inquiéter des commandes internes, mais simplement savoir comment faire un check-in ou commit, check-out ou update, branch, merge … etc etc …. les détails internes n’ont aucun intérêt et surtout en utilisant les concepts plutôt que les commandes, tu peux passer de sourcesafe à svn, à Mercurial, à git, à TFS, à Starteam, à n’importe quoi … sans jamais connaitre quoi que ce soit de la technologie en arrière (dont un développeur n’a strictement rien à foutre).

Au contraire, un développeur devrait connaître la base des lignes de commande. Dev sans console, c’est comme avoir une voiture sans savoir changer un pneu…

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 19/08/2015 à 04h53

pentest a écrit :

30 ans après l’avènement de l’Amiga, les développeurs du libre découvrent toute la puissance d’une interface graphique.    

 

 Dans mon souvenir, le code source (en tout cas des .h de l’API Intuition) contenait des tags RCS  " /> 

 

 

bfaa23dd

Le 12/08/2015 à 19h44

À 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.

hurd Abonné

Le 12/08/2015 à 19h48

Jarodd a écrit :

Et Framagit, pourquoi personne n’en parle " />

" /> Je l’utilise et j’en pense grand bien, mais l’équipe n’a pas encore sortie de logiciel version desktop GUI avec visualisation graphique des branches , donc pas de news " /> .

Zekka

Le 12/08/2015 à 19h49

Plus fermé que ça tu meurs. Well done.

seb2411

Le 12/08/2015 à 21h10

Kernald a écrit :

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…

Tout dépend de l’UI en fait. C’est vrai que la grosse majorité des UI pour Git n’apportent pas grand chose ou sont pas super bien foutus (je reviens toujours à la ligne de commande). Mais justement leur GitHub Desktop m’a l’air sympa. Pour visualiser certaines choses, comme l’arbre des commits avec les branches, les gros diffs, reviser des commits passés, peut être faire du rebase, etc. N’étant pas copain avec Grep une petite interface simple mais claire je dirais pas non.

tom103

Le 12/08/2015 à 21h10

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

Pas à grand chose (et c’est un utilisateur Windows qui parle…)

J’utilisais peu la console avant de passer à Git, mais maintenant je trouve que c’est la façon la plus efficace de manipuler un repo Git.

Le principale intérêt de la GUI selon moi, c’est la représentation graphique de l’historique, qui aide à y voir plus clair. On peut avoir à peu près la même chose en console avec git log –graph, mais c’est quand même moins lisible.

seb2411

Le 12/08/2015 à 21h11

hurd a écrit :

" /> Je l’utilise et j’en pense grand bien, mais l’équipe n’a pas encore sortie de logiciel version desktop GUI avec visualisation graphique des branches , donc pas de news " /> .

Framagit c’est gitlabs il me semble. C’est pas un projet propre à Frama.

Yangzebul

Le 12/08/2015 à 21h45

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.

 

 " />" />" />

Krogoth

Le 12/08/2015 à 21h53

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.

127.0.0.1

Le 12/08/2015 à 22h16

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.

LTourist

Le 12/08/2015 à 22h30

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 ;)

Nikodym

Le 12/08/2015 à 22h32

Yangzebul a écrit :

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.

" />" />" />

" />

127.0.0.1 a écrit :

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.

T’as remarqué ? " />

marba

Le 12/08/2015 à 22h49

shichon64 a écrit :

Plus fermé que ça tu meurs. Well done.

Si on peut plus troller " />

 

Non en vrai je pense que la gui faite par github c’est une très bonne chose, justement ça va permettre aux non informaticiens de contribuer à des projets qu’ils affectionnent en apportant ce qu’ils peuvent sans

pour autant se taper la ligne de commande. La doc, les traductions …

Le défaut des projets libre ou plus généralement info c’est d’être un peut être trop élitiste, je connais des personnes qui auraient voulu améliorer des logiciels qu’ils utilisent, mais ont été rebuté d’entrée par la “complexité” de la chose.

    

Ca ressemble un peu au débat lorsque wikipedia a sorti une interface visuelle pour éditer ses articles, ça a gueulé chez quelques “connaisseurs” comme quoi ça allait permettre au premier venu de faire n’importe quoi. Mais au final ça rend surtout plus facile à tous le monde, dont des personnes qui peuvent beaucoup apporter à la contribution de ces projets.

 

" />

46 75 63 6b 20 6f 66 66

Le 12/08/2015 à 22h50

Mouais, ça va pas me faire quitter Magit tout ça.

 

 ——————————————————————

 

127.0.0.1 a écrit :

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.

Problème culturel.

 

anonyme_f168d692f50618cb9f3fd8cadce4e6bc

Le 12/08/2015 à 23h00

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 !

 

 " />

marba

Le 12/08/2015 à 23h01

Nikodym a écrit :

Pauvre chou. " />
Quand tu affirmes catégoriquement qu'il y a nécessairement plusieurs bonnes façons de  de faire les choses, moi je pose la question. 
Il n’y a peut être pas plusieurs bonnes façons de faire les choses. Mais il y a plusieurs façon de faire de bonnes choses.

 

Ça va peut être amener dans certains cas plus facilement des gens considérés comme “nuisible” aux projets communautaires ou publics, parce que non connaisseurs du fonctionnement de git à la base, mais il faut être réaliste, la plupart des gens qui viennent contribuer, veulent apporter quelque chose à la base. Ça ne peut pas être mauvais. Concernant les projets “fermés” ou limités dans le cadre d’une entreprise, ça ne peut qu’apporter un outil supplémentaire et bénéfique aux projets.

Tehock

Le 13/08/2015 à 01h25

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. " />

seb2411

Le 13/08/2015 à 07h24

127.0.0.1 a écrit :

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.

Pas vraiment GIT te permet de faire du centralisé ou décentralisé il n’a pas changé. Le fait qu’il puisse être complètement décentralisé permet souvent d’avoir des workflow complexe si tu en as besoin.

Après de manière pratique le fait d’avoir un dépôt central de référence reste le plus simple à gérer. Mais après chacun s’organise comme il veut.

plop97

Le 13/08/2015 à 07h29

" />

plop97

Le 13/08/2015 à 07h33

Aucun rapport

count0

Le 13/08/2015 à 07h53

wagaf a écrit :

Le meilleur pour moi est SmartGit http://www.syntevo.com/smartgit/

Hélas non libre, mais tellement efficace…

+1 pour le moment j’ai pas vu mieux 

TexMex

Le 13/08/2015 à 08h12

 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 :

Une solution qui fonctionne à 100% en local (pas sur un service externe). Si elle peut faire les deux; tant mieux.

Utilisable avec n’importe quel éditeur de préférence Geany

Capacité de pusher d’un fork a l’autre. J’explique. Si je Fork A en A’. Je me rend compte d’un bug en développant A’ et je le corrige à la volé dans le fichier incriminé sur le fork A’ (parce que j’ai pas fais gaffe a revenir sur le contexte de A), de pouvoir copier le fichier de A’ sur A. Ca aurait été mieux de se remettre dans le contexte de A mais bon on est tous tête en l’air. Y’aurai pas de programmeur s’il n’y avait pas de tête en l’air.

 Pourvoir rendre le pack de fichier dans un répertoire de mon choix et d’exécuter des commandes après la création du pack. Ex: création des fichiers dans /var/www/web/montruc-20150813-080000 (enfin une date quoi) et exécution d’un ln -s /var/www/web/montruc-20150813-080000 /var/www/current ou un Gzip peu importe.

L’interface graphique ça a du bon parfois.

Des tutoriels avec. Les MANs sont parfois drôlement… nazes.

 Que le meilleur gagne.

 Merci bien.

count0

Le 13/08/2015 à 08h29

Visiblement le setup launcher download fourni GitHubSetup.exe ne gère pas les proxy ?

anonyme_92fcfbdd6cc3f0397af3a985adab6b1b

Le 13/08/2015 à 08h36

TexMex a écrit :

Un mal à l’aise permanent ou tu dois polus retenir dans quoi tu es que d’y réfléchir.

Comme dans Caxtor et Polus?

sephirostoy Abonné

Le 13/08/2015 à 09h11

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

mahn

Le 13/08/2015 à 09h50

Git ne permet pas tous ça ?

Pour du 100% local, installe toi un github sur ton pc mais je trouve l’intérêt limité de l’avoir en local.

je comprend pas :/ Tu veux gérer ton git depuis l’éditeur ? Perso j’utilise atom qui dispose de tonne d’extension mais pas de gestion avancé des dépôts git à ma connaissance.

Git permet de merge les forks.

Utilise les hooks, très efficaces. je m’en servais avec puppet. Dès que je push une nouvelle modification, mon github ce connecte au serveur puppet et récupère la dernière version pour déployement (mais tu peut lui faire passer les taches que tu veut)

J’ai surement pas bien compris ce que tu demandais mais j’ai répondu ce qui me semblais adapté.

127.0.0.1

Le 13/08/2015 à 10h37

TexMex a écrit :

Ce que je cherche :

D’une menière générale “ce que je cherche” n’existe jamais à 100%. Sauf a coder soi-même son propre RCS (*) => Les RCS existant sont le “ce que je cherchais” d’un développeur (ou d’un groupe de développeurs).

Donc soit on adhère à 100% à la manière de travailler de ce développeur, soit on s’accomode des manques/contraintes de la solution (on fait sans, on coutourne, on utilise des outils tiers, …)

C’est pour cela que je disais que c’était marrant de voir que la “communauté” a recréée un semblant de centralisation, là où l’auteur voyait un truc complètement décéntralisé.

(*): Ce que j’ai fait… et si j’ai un conseil: ne le faites pas !! " />

anonyme_751eb151a3e6ce065481d43bf0d18298

Le 13/08/2015 à 11h00

sephirostoy a écrit :

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

Ligne de commande, un outil des années 70 ?

Ce n’est pas parce que certains trollent sur la GUI que tu dois faire la même chose sur la CLI… " />

anonyme_92fcfbdd6cc3f0397af3a985adab6b1b

Le 13/08/2015 à 11h28

mahn a écrit :

Git ne permet pas tous ça ?

[list][*]Pour du 100% local, installe toi un github sur ton pc mais je trouve l’intérêt limité de l’avoir en local.[

si t’as un réseau local, voir un VPN, tu peux utiliser git sans le moindre serveur. Tu as juste besoin du client git et d’un répertoire pour le repo. Pas besoin de serveur du tout, un simple NAS suffirait.

Techniquement, ça n’empêche pas de tout faire en local sur le même pc, mais le commit fait déjà ça. Donc je vois pas trop l’intérêt.

DomabaZ

Le 13/08/2015 à 11h34

gokudomatic a écrit :

si t’as un réseau local, voir un VPN, tu peux utiliser git sans le moindre serveur. Tu as juste besoin du client git et d’un répertoire pour le repo. Pas besoin de serveur du tout, un simple NAS suffirait.

Techniquement, ça n’empêche pas de tout faire en local sur le même pc, mais le commit fait déjà ça. Donc je vois pas trop l’intérêt.

L’intérêt serait sans doute de pouvoir revenir dans l’historique facilement.

anonyme_92fcfbdd6cc3f0397af3a985adab6b1b

Le 13/08/2015 à 11h39

DomabaZ a écrit :

L’intérêt serait sans doute de pouvoir revenir dans l’historique facilement.

mais on peut déjà faire ça avec les commits

TexMex

Le 13/08/2015 à 11h46

@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.

 

 

mahn

Le 13/08/2015 à 12h05

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.

catseye

Le 12/08/2015 à 16h54

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

A éviter de taper des lignes de commandes pleines d’erreurs qui viennent niquer ton projet … et quand tu gères 3 ou 4 repo Git et des centaines de projets, t’es bien content d’avoir un aperçu global et standard …

En fait j’utilise que le UI ou l’intégration dans Visual Studio, jamais eu besoin de taper une seule ligne de commande depuis des siècles …

Naneday

Le 12/08/2015 à 17h02

Pour ceux qui dev de vrais projects avec plus de 1000 fichiers, pas de simple flappy-bird clone ;)

hurd Abonné

Le 12/08/2015 à 17h04

catseye a écrit :

A éviter de taper des lignes de commandes pleines d’erreurs qui viennent niquer ton projet …

J’ai du mal à voir pour quel raison une erreur de ligne de commande pourraît plus facilement niquer ton projet qu’un clic au mauvais endroit sur une interface graphique .

Après effectivement git standard n’est clairement pas fait pour avoir un aperçu global entre plusieurs dépôt, mais je ne doute pas que certains se soit essayer à créer ce genre de logiciel en ligne de commande.

Je pense que c’est plus une question d’habitudes qu’autre chose. pour les développeurs qui ne sont rodés à la ligne de commande ou qui n’aime pas trop ça pour diverse raison, c’est pas plus mal.

nirgal76

Le 12/08/2015 à 17h14

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

Ou aussi : “Ca sert à quoi d’avoir plus de 640ko de ram dans un pc ?”

Kernald

Le 12/08/2015 à 17h24

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…

Jarodd Abonné

Le 12/08/2015 à 17h25

Et Framagit, pourquoi personne n’en parle " />

Gormador

Le 12/08/2015 à 17h35

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.

Kernald

Le 12/08/2015 à 17h37

Je ne dis pas que les interface graphiques sont le mal, clairement. Mais l’exemple de @Naneday était asse mal choisi pour le coup !

thib_b

Le 12/08/2015 à 17h38

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.

Salamandar

Le 12/08/2015 à 17h41

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’

Salamandar

Le 12/08/2015 à 17h46

“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 ?

lossendae

Le 12/08/2015 à 18h06

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.

brazomyna

Le 12/08/2015 à 18h24

Nikodym a écrit :

Ça sert à quoi une GUI pour git ?

Je me demande si le plus navrant c’est ce comm’ de collégien en vacances, ou si ce sont les 20 suivants qui alimentent le troll.

 

lossendae

Le 12/08/2015 à 18h38

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 !  " />

Nikodym

Le 12/08/2015 à 19h34

catseye a écrit :

A éviter de taper des lignes de commandes pleines d’erreurs qui viennent niquer ton projet … et quand tu gères 3 ou 4 repo Git et des centaines de projets, t’es bien content d’avoir un aperçu global et standard …

En fait j’utilise que le UI ou l’intégration dans Visual Studio, jamais eu besoin de taper une seule ligne de commande depuis des siècles …

Une ligne de commande qui nique le projet ? Wtf ?

Naneday a écrit :

Pour ceux qui dev de vrais projects avec plus de 1000 fichiers, pas de simple flappy-bird clone ;)

Genre le noyau Linux ? " />

Kernald a écrit :

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…

+1000 " />

Antwan a écrit :

Sinon git log –oneline –abbrev-commit –all –graph –decorate –color.

sg pour short graph

git config –global alias.sg ‘log –oneline –abbrev-commit –all –graph –decorate –color’

git sg

" />

GitHub

Nikodym

Le 12/08/2015 à 19h41

brazomyna a écrit :

Je me demande si le plus navrant c’est ce comm’ de collégien en vacances, ou si ce sont les 20 suivants qui alimentent le troll.

Pauvre chou. " />

lossendae a écrit :

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 ! " />

Quand tu affirmes catégoriquement qu’il y a nécessairement plusieurs bonnes façons de de faire les choses, moi je pose la question. " />

mahn

Le 13/08/2015 à 12h06

ha pardon j’ai dit github ? je pensais gitlab :/

Et oui atom, c’est … comment dire … un couteau suisse ;)

46 75 63 6b 20 6f 66 66

Le 13/08/2015 à 14h11

plop97 a écrit :

Aucun rapport

Depuis combien de temps?

C’est pas trop dur?

Nikodym

Le 13/08/2015 à 14h20

TexMex a écrit :

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 :

* Une solution qui fonctionne à 100% en local (pas sur un service externe). Si elle peut faire les deux; tant mieux.

Git.

TexMex a écrit :

* Utilisable avec n’importe quel éditeur de préférence Geany

Je ne sais pas, j’utilise personnellement neovim. Néanmoins, vu la popularité de git, ça m’étonnerait qu’il n’existe pas de prise en charge.

TexMex a écrit :

* Capacité de pusher d’un fork a l’autre. J’explique. Si je Fork A en A’. Je me rend compte d’un bug en développant A’ et je le corrige à la volé dans le fichier incriminé sur le fork A’ (parce que j’ai pas fais gaffe a revenir sur le contexte de A), de pouvoir copier le fichier de A’ sur A. Ca aurait été mieux de se remettre dans le contexte de A mais bon on est tous tête en l’air. Y’aurai pas de programmeur s’il n’y avait pas de tête en l’air.

Je présume que tu voulais parler de branches et pas de forks :

(master) : git checkout -b featA

Je me rends compte d’un bug que je corrige dans featA

(featA) : git commit -a -m “correction de bug#42”

(featA) : git checkout master

Je rapatrie la correction dans master

(master) : git cherry-pick 13e7

Où 13e7 est le sha-1 du commit “correction de bug#42”

Mais : tu risques de perde l’historique des commits. (au lieu d’avoir un historique A->B->C->C’ tu auras : A–>C’. Avec les commits B et C compactés dans un seul (C’).

man git-cherry-pick

La meilleure façon de faire reste de créer une branche spécifique à la correction du bug depuis master et de faire un merge dans master après les tests, et de rapatrier si nécessaire les changement dans la branche featA.

https://git-scm.com/book/fr/v1/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0…

Il faut en user et abuser. " />

TexMex a écrit :

* Pourvoir rendre le pack de fichier dans un répertoire de mon choix et d’exécuter des commandes après la création du pack. Ex: création des fichiers dans /var/www/web/montruc-20150813-080000 (enfin une date quoi) et exécution d’un ln -s /var/www/web/montruc-20150813-080000 /var/www/current ou un Gzip peu importe.

Je n’ai pas compris. " />

TexMex a écrit :

* L’interface graphique ça a du bon parfois.

" />

TexMex a écrit :

* Des tutoriels avec. Les MANs sont parfois drôlement… nazes. Que le meilleur gagne.

Merci bien.

https://git-scm.com/book/en/v2

Nikodym

Le 13/08/2015 à 14h24

PCI devrait abandonner cet éditeur bbcode de caca et passer à Markdown. " />

TexMex

Le 13/08/2015 à 14h55

Y’a des moments c’est vrais que ça pêche un peu.

TexMex

Le 13/08/2015 à 14h59

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é.

 

catseye

Le 13/08/2015 à 16h02

Krogoth a écrit :

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.

Tu maitrises parfaitement ce que tu fais vu que c’est harcodé dans le UI et non modifiable, contrairement à taper toi même des caractères sur la console.

mahn

Le 13/08/2015 à 16h06

TexMex a écrit :

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é.

 

Je t’ai répondu plus top que dans gitlab (gît uniquement je ne sais pas ) tu peux faire des hooks qui sont des scripts qui fond ce que tu leur demande. Ça peu être avant,après un push.

Très pratique pour automatiser une maj sur un serveur des que tu viens de faire ton push par exemple.

Dans mon cas le script ce connecte au serveur lance la maj et j’ai le retour directement dans ma console avec erreur si il y as.

Nikodym

Le 13/08/2015 à 17h41

TexMex a écrit :

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é.

D’accord, ce que tu veux faire est hors de la portée d’un CVS.

Néanmoins, ce que tu peux faire, c’est tagger[1] un état spécifique puis délaisser le reste à des scripts2

[1]https://git-scm.com/book/fr/v1/Les-bases-de-Git-%C3%89tiquetage

[2]http://www.fabfile.org/

J’aimerai revenir sur ma réponse d’au dessus, en disant que ce n’est pas un bon workflow.

Nikodym a écrit :

Je présume que tu voulais parler de branches et pas de forks :

(master) : git checkout -b featA

Je fais beaucoup de modifications.

Je me rends compte d’un bug que je corrige dans featA

(featA) : git commit -a -m “correction de bug#42”

Je fais beaucoup de modifications.

(featA) : git checkout master

Je rapatrie la correction dans master

(master) : git cherry-pick 13e7

Où 13e7 est le sha-1 du commit “correction de bug#42”

Tant que tu n’as pas commit ou indexé des changements, tu peux créer une branche avec les nouvelles modifications simplement en faisant : git checkout -b branch_name

On peut effectivement dans la plupart des cas faire autrement qu’un cherry-pick

Krogoth

Le 13/08/2015 à 17h41

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.

lossendae

Le 13/08/2015 à 17h44

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.

 

lossendae

Le 13/08/2015 à 17h45

+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 !

TexMex

Le 13/08/2015 à 18h30

ok mais y’a quoi d’autre comme solution? Bon le classique CVS mais après ?

mahn

Le 13/08/2015 à 19h28

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.

TexMex

Le 13/08/2015 à 20h22

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.

  

brazomyna

Le 13/08/2015 à 20h59

lossendae a écrit :

je suis prêt à parier que beaucoup commente moins voire plus du tout à cause de ce truc vraiment mal fini. Pas glop !
  Soit ça, soit la "qualité" des commentaires qui fait fuir.   
Et devais choisir entre les deux alternatives (et bien que je trouve cet éditeur de comm juste horrible), je prendrais quand même le pari.   


&nbsp;

Catégories

Nous Suivre

À propos

GitHub Desktop 3.0 est là, avec une visualisation graphique des branches

Un petit dessin peut vous changer la vie

Commentaires (83)