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

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

Un petit dessin peut vous changer la vie

83

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

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.

GitHub Desktop 3.0

Commentaires (83)


Toujours pas de version Linux prévue ?


Ça sert à quoi une GUI pour git ?








Nikodym a écrit :



Ça sert à quoi une GUI pour git ?





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



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 …


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.








seb2411 a écrit :



Toujours pas de version Linux prévue ?





Malheureusement :‘(



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



Hélas non libre, mais tellement efficace…








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…









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 <img data-src=" />).









Nikodym a écrit :



Ça sert à quoi une GUI pour git ?





<img data-src=" />



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.

&nbsp;

Pour les pull request, je fait ça depuis github directement.

&nbsp;



&nbsp;Ça suffit comme consigne en interne pour que les différents profils évitent les conneries;)


likelikelikelikelikelike&nbsp;


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








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 …



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








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.









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



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…


Et Framagit, pourquoi personne n’en parle <img data-src=" />


Ceci. Tellement vrais.

&nbsp;

&nbsp;J’utilisais git en graphique avant. Et puis, nouveau boulot, nouvelles pratiques: bash! Eh bah j’y retournerai pas, à cette interface.

&nbsp;Bon, c’est vrais que le site de github propose des trucs cools, genre pour les PR et les releases.


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


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.


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.

&nbsp;



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”&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; %C(bold red)%s%C(reset)%n”%w(0,14,14)%b’


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


cmder ou git bash font largement l’affaire.

&nbsp;

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.








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.

&nbsp;



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 !&nbsp; <img data-src=" />








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 ? <img data-src=" />







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 <img data-src=" />







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

<img data-src=" />



https://github.com/git/git/blob/master/contrib/completion/git-completion.bash









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. <img data-src=" />







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 !  <img data-src=" />





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. <img data-src=" />



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








Jarodd a écrit :



Et Framagit, pourquoi personne n’en parle <img data-src=" />





<img data-src=" /> 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 <img data-src=" /> .



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








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.









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.









hurd a écrit :



<img data-src=" /> 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 <img data-src=" /> .





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



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.

&nbsp;

&nbsp;Manquerai plus qu’une petite regex et ce serait l’orgasme.

&nbsp;

&nbsp;<img data-src=" /><img data-src=" /><img data-src=" />


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.


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.


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.

&nbsp;

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



&nbsp;@yellowiscool SourceTree n’arrive pas à la cheville de GitExtensions (qui au passage semble tourner sous linux et mac). Réellement ;)








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.

 

 <img data-src=" /><img data-src=" /><img data-src=" />





<img data-src=" />







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é ? <img data-src=" />









shichon64 a écrit :



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





Si on peut plus troller&nbsp;<img data-src=" />

&nbsp;

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.

&nbsp;&nbsp; &nbsp;

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.

&nbsp;



<img data-src=" />



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

&nbsp;

&nbsp;——————————————————————

&nbsp;







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.



&nbsp;



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

&nbsp;

Champagne !

&nbsp;

&nbsp;<img data-src=" />








Nikodym a écrit :



Pauvre chou. <img data-src=" />






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. :fumer:







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.

&nbsp;

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



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.

&nbsp;

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. <img data-src=" />








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.



<img data-src=" />


Aucun rapport








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&nbsp;



&nbsp;Je code depuis le ST et l’Amiga et j’ai jamais accroché ces solutions.



&nbsp;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).&nbsp; Puisqu’il y a des Guru du Fork autoproclamé ou pas voici ma question



&nbsp;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.

  • &nbsp;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.&nbsp;

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

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



    &nbsp;Que le meilleur gagne.



    &nbsp;Merci bien.

    &nbsp;


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








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?



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


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








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 (*) =&gt; 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 !! <img data-src=" />









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… <img data-src=" />









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.









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.









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



@Mahn & @127.0.0.1

&nbsp;

&nbsp;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.



&nbsp;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.

&nbsp;



&nbsp;


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.


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

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








plop97 a écrit :



Aucun rapport





Depuis combien de temps?



C’est pas trop dur?









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-&gt;B-&gt;C-&gt;C’ tu auras : A–&gt;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. <img data-src=" />







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. <img data-src=" />







TexMex a écrit :



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





<img data-src=" />





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



PCI devrait abandonner cet éditeur bbcode de caca et passer à Markdown. <img data-src=" />


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


Pour le pack.

&nbsp;

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



&nbsp;








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.









TexMex a écrit :



Pour le pack.

&nbsp;

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



&nbsp;





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.









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



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 un peu à géométrie variable si tu prefères.

&nbsp;

&nbsp;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”.

&nbsp;

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.

&nbsp;


+100000

&nbsp;

&nbsp;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 !


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


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.


Quand je-vous parlais-parlera de solution je pensai-pensera de produits (moment culture).



&nbsp;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.

&nbsp;&nbsp;








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. :fumer:  






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. :D  

&nbsp;


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

&nbsp;

Merci pour le lien, tu ne pouvais pas mieux tomber je suis en train de regarder ça :http://www.imdb.com/title/tt0076929/








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 ? <img data-src=" />), je suis entouré de barbus.









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



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…








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…









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. &nbsp; &nbsp;



&nbsp;

&nbsp;Dans mon souvenir, le code source (en tout cas des .h de l’API Intuition) contenait des tags RCS &nbsp;<img data-src=" />&nbsp;

&nbsp;

&nbsp;



Fermer