Voici un article trollesque en perpective. En fait j’aimerais bien, parce qu’au-delà de doper mes statistiques, ça voudrait dire que git est efficace et que je suis un menteur, donc que je n’ai jamais fait l’expérience que je vais vous relater.
Commençons par une petite définition. Programmer est une activité délicate qui demande beaucoup de concentration, et toute la partie logistique de la programmation, bien que passionnante, doit se faire aussi transparente que possible. Pousser son code quelque part ou ajouter le code de son voisin au sien doit être une étape simple, avec des commandes simples (si on doit regarder la page de man c’est foutu).
Vous n’êtes pas sans savoir que je me suis retrouvé impliqué dans le projet Movim, un réseau social libre basé sur XMPP, lequel utilisait git à l’époque. Il n’y avait qu’un seul dévelopeur, donc le workflow était très simple et n’importe quel VCS aurait fait l’affaire.
Suite à mon arrivée dans le projet, nous avons mit en place un workflow similaire à celui employé dans le noyau linux pour le projet, c’est à dire que chacun travaille sur une feature dans son coin et on merge dans le master (sorte de branche commune au projet) quand c’est mûr. Jusque là rien de compliqué.
Sauf que git ne l’entendait apparemment pas de cette oreille. Ainsi nous perdions environ une heure à chaque merge à essayer de comprendre pourquoi diable git ne voulait pas fusionner nos changements. C’est ainsi que lors d’un merge, les messages d’erreurs de l’outil étaient trop cryptiques pour moi, et donc comme d’habitude quand je suis dépassé, je demande de l’aide. Je me suis pointé sur le salon IRC de git, et quelques bonnes âmes expérimentées ont essayé de m’aider. Sans succès. Au final j’ai décidé de fusionner les deux codes à la main (enfin avec emacs et emerge) puis commiter, très sale mais au bout de 2h face à un mur, on n’est plus à ça près.
Après deux ou trois sorties de Movim à faire face à ce problème sans que la situation s’améliore (oui on pensait que c’était notre faute), nous avons finalement décidé d’arrêter les frais et de tenter le coup avec un autre VCS; n’importe lequel. On nous a chaudement conseillé Mercurial, et Bazaar un peu moins. Mais Mercurial ressemblait un peu à git et chat échaudé craint l’eau froide. Qui plus est j’avais déjà eu l’occasion d’utiliser Bazaar dans un workflow centralisé (comme subversion), et donc connaissais sa versatilité.
Nous avons donc décidé de faire la sortie suivante sur bazaar en synchronisant sur git (au cas où). Et nous avons été ébahi lorsque bazaar ne s’est pas une seule fois plaint, que les conflits étaient très explicitement indiqués et finalement nous sommes passés d’1h par merge à 5 minutes.
Depuis il m’arrive de voir des articles qui vantent les mérites de git contre d’autres, et c’est sûrement vrai qu’il est techniquement très efficace, voire supérieur, mais ce n’est pas un outil fait pour aider le programmeur.
Disclaimer : Je suis un fan absolu de Git et l’utilise presque exclusivement.
En fait, Git est absolument génial de par sa flexibilité. Personnellement, je suis assez bordélique (le mot est faible), et j’ai du mal avec les workflows stricts (j’y perds du temps, je dois sans arrêt me demander si je peux faire ce que je fais, etc…)
Du coup, ma méthode de développement c’est : bosse en local, committe comme un porc comme ca vient, et quand tu es content, réécrit ton historique pour avoir des commits atomiques propres avec des messages de commit appropriés et explicatifs.
Git se prête formidablement bien à mon workflow bordélique, et c’est (de par mon experience) le seul avec lequel je n’ai pas l’impression de me battre.
Git est en quelques sortes un outil complètement timbré, puisqu’il me laisse avoir le workflow qui me convient, même s’il est (comme moi) complètement farfelu.
Voila pourquoi je suis tellement fan de Git.
En revanche, force est de constater que Git a une UI de merde, et le mot n’est pas trop fort.
Tu l’as dit, les messages d’erreurs sont totalement cryptiques et absolument « unhelpful » (mince, j’ai oublie comment dit ca en Francais :-/).
Mais aussi, les commandes sont totalement incohérentes !
Par exemple, pour renommer une branche, on utilisera l’option « -m » (comme « move »), alors que pour renommer une remote, on utilisera l’option… « rename ». WAT?! o_O
Et c’est comme ça partout. C’est à mon avis le (seul ?) gros point positif de Mercurial : un réel effort a été fait sur la cohérence des commandes et options.
Au final, Git a l’air d’un fatras d’outils décousus parlant une langue qui est au Klingon ce que la confiture est au meuble à chaussures… et c’est un peu le cas. :-/
Je pense que c’est ça qui cause la courbe d’apprentissage Everestistique de Git, et c’est celle-ci qui à son tour donne l’impression aux débutants qu’ils passent leur temps à se battre contre l’outil.
Personnellement, je suis convaincu que l’air est plus pur au sommet de la courbe, mais c’est peut-etre simplement parce que j’ai du faire un effort important pour m’y retrouver (un peu comme on trouve toujours meilleur un gateau qu’on a fait soi-même).
En revanche, j’ai peu d’espoir que les choses s’améliorent, car les développeurs de Git semblent parfaitement heureux de cette courbe d’apprentissage, puisqu’elle permet de réserver leur outil à une certaine « élite » (note les guillemets
) dont ils font forcément partie (puisqu’ils la créent eux-même). Et du coup, énormément de gens passent à côté de ce formidable outil qui aurait, peut-être, été plus approprié que leur outil actuel pour certaines de leurs tâches. 
M’enfin bon, la seule chose qui compte au final c’est que le développement de Movim s’en trouve accéléré, le reste, c’est un détail d’implémentation.
PS : Désolé pour le pavé. ^_^
Hello,
il aurait quand même été intéressant d’avoir une petite explication sur les problèmes rencontré afin de voir si d’autres peuvent-être dans ton cas …
Hélas, cela date et j’ai oublié lesdits détails
Je vois mal comment cet article pourrait donner lieu à un débat de trolls vu que toute personne qui s’est un tant soit peu frottée à GIT est forcement arrivé au même constat que toi : c’est inbitable. D’ailleurs je vais regarder bzr de plus prés, ne serait-ce que pour les gens avec qui je travaille et qui à chaque fois que je leur dit « il faut utiliser git sur mon projet », deviennent tout blanc… Et quant je leur demande pourquoi ils me répondent « Non, GIT est très bien vu que tout le monde le dit, mais la dernière fois que je l’ai utilisé, j’ai vraiment eu très mal… ».
Ceci étant dit GIT est un peu comme le reste de l’outillage UNIX… Je ne sais pas pour vous mais aujourd’hui je ne sais même plus pourquoi je tapes « ps -edaf » ou « netstat -anlp »
A ce titre, GIT peut presque être vu comme une API bas niveau permettant de construire des outils de plus haut niveau (l’option –porcelain est presque la plus homogène de la batterie). Et c’est cet aspect « bas niveau » qui permet, comme l’explique si justement Bochecha, d’adapter l’outil à tous les usages. C’est cela qui moi me plait avec GIT et qui me permet de l’utiliser certes pour le dev, mais aussi en couche de stockage de mes informations personnelles, en outil de synchronisation multi-poste, en outil d’historisation de documents automatisé (git+inotify), etc…
Mais du coup on finit, nous sommes bien d’accord, avec une batterie d’alias/script de « haut niveau » pour ne plus avoir à saisir des lignes de commandes cryptique et aussi un peu décoder leurs résultats. Et dans le même esprit, je pense que tout utilisateur régulier de GIT maintient ça propre liste de formules magiques qu’il garde précieusement sous le coude
Je ne suis pas vraiment d’accord. git n’est pas un petit outil KISS a la Unix, de plus il ne correspond pas du tout a l’esprit unix a la base, et ses défenseurs le vantent sans arrêt: dans git tout est contenu. Dans unix, tout est fichier…
Hum… C’est quoi la différence entre « tout est contenu » et « tout est fichier » exactement
Ou alors par « contenu » tu entends « contenu dans git » et tu vises alors son côté « busy-box » (commande/sous-command).
> Je vois mal comment cet article pourrait donner lieu à un débat de trolls vu que toute personne qui s’est un tant soit peu frottée à GIT est forcement arrivé au même constat que toi : c’est inbitable.
Non, ça, c’est faux. Il y a plein de gens qui connaissent bien Git et qui adorent ça.
J’adore développer en assembleur, mais c’est inbitable. Je ne vois pas pourquoi quelque chose d’inbitable et d’adorable serait forcément antinomique…
Maintenant je pense me placer dans la catégorie des gens qui connaissent bien git, ça fait 3 ans que je n’utilise que cela tout les jours, mais cela ne change rien au fait qu’il faudrait sérieusement homogénéiser les commandes, les options et surtout rendre les messages d’erreurs un peu plus compréhensibles (euphémisme).
Complètement d’accord avec cet article. J’ai connu SVN puis Mercurial, et Git est pour moi d’un flou monstrueux !
À chaque fois que je veux contribuer sur un projet héberger sur GitHub je dois relire la doc pour être sur de ce que je fais. Et encore, heureusement que c’est du GitHub et pas du Git pur, leur interface et leur gestion de compte aide beaucoup et facilite l’utilisation de Git à plusieurs !
Tout comme G-rom je suis passé de SVN à Mercurial.
Mercurial est un outils super !! J’insiste, simple concis et surtout clair ! Il est très simple à prendre en main, et les commandes sont faîtes pour être utilisées sans option dans leur utilisation principale. (ce qui évite quand même d’apprendre le manuel par coeur pour s’en servir).
Le site bitbucket est agréable mais comparé à Github il est plus limité. C’est surtout là que j’y vois le succès de GIT. Si l’outils est merdique à souhait, Github est très agréable à utiliser.
Car comme tout le monde je suis amené à travaillé sur un projet publié sur Github et un commit sur deux, il y a une merde… l’outil est déplorable, conçue dans tous les sens, sans une once de bon sens et d’effort pour obtenir un outils un minimum homogène.
Bref je rêve secrètement qu’un jour Mercurial deviennent l’outil de prédilection des développeurs.
Git est très compliqué à prendre en main, mais une fois fait, c’est que du bonheur.
J’ai moi même pas mal galéré pour mettre Git en place chez moi.
J’ai fait quelques reset repository de mon dépôt central.
Pour les messages d’erreur, c’est totalement vrai. Git nous balance un message pratiquement générique pour n’importe quelle erreur complexe moyennement.
Genre l’auth qui passe pas, hop message à la con qui veut rien dire.
Ce fait maintenant un an que je suis avec git et je ne le regrette pas.
J’avais le choix entre mercurial et git, mais il y a un an, on parlait de git partout.
Et puis avec git extension on à un GUI du tonnerre.
Pour les merges, j’utilise p4merge (ou meld sous linux). Mais vu que je taff dans mon coin et ma femme pareil, c’est assez rare d’avoir un conflit.
Mon seul soucis, la mise à dispo anonyme via git:// de mes sources. J’ai du passer par http://
> Mon seul soucis, la mise à dispo anonyme via git:// de mes sources. J’ai du passer par http://
Quel problème au juste avec le service Git natif ?
Bha, ca passe pas avec le git natif. J’ai pas utilisé -bare à la création du projet.
La solution propre :
…/monProj $ cd ..
… $ git clone –bare monProj
… $ cd monProj.git
…/monProj.git $ git remote rm origin
Tu as un dépôt comme tu veux dans monProj.git. Reste plus qu’a fournir le remote là où tu édites les sources. Un petit git remote add myPublic ../monProj.git et tout roule.
ok, je note pour plus tard.
Bonjour,
personnellement je fais partie des inconditionnels de git. Dans le cadre de mon travail, nous hébergeons des projets de développement dont certains doivent être visibles via des instances redmine (les autres devant justes pouvoir être commités de manière locale puis centralisée) et ce depuis divers sites en franque, avec des personnes ayant des expériences « diverses » dans le domaine du développement.
Nous avons mis en place le trio git/gitolite/redmine et tout marche à merveille. Gitolite est l’outil qui nous a demandé le plus de temps de configuration.
pour le reste une petite doc, le cas échéant une petite présentation/formation d’une heure sur le fonctionnement général, git et redmine, et depuis presque un an nous n’avons aucun souci.
Récemment, un client nous a demandé de mettre en place la même chose avec svn (que je ne connaissais que de nom) ,sans gitolite bien sûr, et pour ce qui est des messages imbitables réservés aux bilingues mandarin de l’extrême nord en date du IXème siècle avant Confucius nous avons été servis, mais c’était leur choix et leur affinité, alors nous l’avons fait.
A mon avis, vouloir élire le meilleur CVS est vain, il faut juste choisir en fonction de ses affinités et de son expérience personnelle. Comme pour les FAI, les distrib linux, les smartphone, etc…
Les filles…
(Au fait, « ma femme et moi, on travaille dans notre coin et on commit avec git », c’est juste abusé comme phrase
)
J’ai utilisé git pendant quelques mois durant une mission.
Je trouve l’outil excellent. Mais comme tout bon outil, il est difficile à maîtriser. Pour nous aider, les commandes sont toutes très bien documentées. Je n’ai jamais eu de problème de merge.
Je suis d’accord que git demande un peu d’effort, mais dans le git status, il donne les commandes possible pour revenir en arrière. L’aspect décentralisé et ajout de nouvelle commande facilement est un plus en entreprise pour adapter le process. Mercurial et bazaar n’ont pas le second (à ma connaissance) .
Tous les outils de gestion de conf que je connais demande une compréhension minimale pour être bien utilisé.
Ce qui a été dur avec git, c’est la compréhension de son fonctionnement avec les « remote ».
Un petit doc sympa :
http://excess.org/article/2008/07/ogre-git-tutorial/
http://www.moussu.fr/git/
Ce qui me fait peur avec les outils « simple ». Car dès qu’on a un besoin particulier sur un projet, ils ne savent pas s’adapter.
J’ai travailler avec git pendant a peu prés une année dans un team de 3/4 développeurs. Nous avions au départ ces problèmes de merge. Le chef de projet s’est renseigné sur la toile (ou sur la doc) a fait quelques petits réglages et tout a roulé comme sur des roulettes le reste de l’année.
Marrant tous ces gens qui se plaignent de git (tout du moins ici, sinon c’est beaucoup moins le cas) mais qui, au final je pense, ne savent simplement pas s’en servir. Je dis pas que c’est simple pour s’y mettre simplement que l’outil fonctionne très bien une fois qu’on a compris comment il marchait.
Ça fait quelques années maintenant que je développe avec, et pour rien au monde je repasserai vers du svn (mercurial je sais pas, jamais trop joué avec). Mais quand j’ai voulu m’y mettre, ben le premier truc que j’ai fait plutôt que d’essayer de reproduire ce que je faisais à l’époque avec SVN, ça a été de lire de la doc, et si possible de la bonne.
J’en suis rapidement venu à me procurer le bouquin sur git de chez pragmatic programmers et pour le coup ça éclaire bien. Après on trouve un bouquin gratuitement sur le net que beaucoup trouvent très bien, Pro Git : http://progit.org/book/
À l’heure actuelle je travaille toujours avec git (comme tout le reste de ma boite), on a jamais eu des soucis de merge (sauf quand y’a des conflits mais ça arrive forcément de temps en temps, c’est normal) et accessoirement on utilise aussi git flow pour notre workflow.
Voilà je sais pas si ça peut en aider quelques uns, mais perso je pense que tes critiques sont à prendre avec pas mal de recul.
Le problème c’est qu’il y a déjà suffisemment à faire sur la programmation sans avoir en plus à perdre du temps sur un outil de logistique.
Git n’a pas d’excuse car beaucoup de ses concurrents réussissent à se faire invisibles avec un apprentissage très faible, ce qui n’est pas le cas de git. Il est peut-être techniquement supérieur, mais s’il romp le rythme de travail du programmeur, c’est un obstacle et non une aide.
Je ne suis pas d’accord, la gestion de conf fait partie intégrante du dévelopement. En fonction de la complexité de ton appli, tu décides de ton processus de dév, et tu adaptes la gestion de conf à ton process. Si cette dernière étape n’est pas possible, alors, il faut changer d’outils.
Non, le vrai truc c’est de savoir si la courbe d’apprentissage d’un outil vaut le coup ou non. Devoir s’investir pour apprendre de nouveaux outils, ça fait partie du métier de développeur (ou alors faut aller faire autre chose) surtout quand au final cela permet d’être plus productif.
À partir du moment où tu as fait l’effort d’apprendre à te servir correctement de l’outil, c’est rare que ce dernier te colle des bâtons dans les roues. Si c’est le cas, c’est que c’est un mauvais outil, mais la plupart du temps le problème ne se situe pas à son niveau.
Avec le raisonnement de ta première phrase, tu ne progresses pas beaucoup et au final c’est dommageable pour tes propres compétences.
Tu pars du principe que maîtriser git est un atout et que donc ne pas le connaître m’est dommageable. Mais git n’est pas seul dans sa catégorie, et d’autres outils remplissent le même office sans demander un tel investissement.
De plus l’article est écrit du point de vue du choix d’un VCS pour un projet, et non d’un apprentissage personnel. Le fait est que Bazaar a rempli parfaitement les besoins du projet tout en évitant l’apprentissage difficile de git que tu mentionne.
Mon but ici n’est même pas de dire que « X est meilleur que git », juste que git n’est pas forcément un bon choix lorsqu’il s’agit de déterminer que outil prendre pour un projet (et quand on n’en connait aucun ou qu’on débarque de subversion).
Je crois qu’il te dit que la gestion de conf doit être maîtrisée, au même titre que le language, mais aussi ton environnement de dév. (emacs, vim… visual, kdevelop, eclipse…) sans maîtrise de toutes les composantes du dév. tu perdras du temps. La gestion de conf n’est finalement qu’un maillon, si tu trouves une gestion de conf à ton goût, apprend à la maîtriser. Tu gagneras un temps fou. C’était, je crois, ça son propos. Ce qui est différent de « Si tu maîtrise pas git t’es une bille. » comme tu sembles l’avoir compris.
@capello, oui c’était bien le sens de mon propos, merci d’avoir précisé
Je suis pas toujours très clair pour expliquer des trucs 
Bah un article que donne un point de vue s’appuyant sur une expérience n’est pas un troll…
Les commentaires qui s’en suivent peuvent le devenir
Pour ma part même expérience douloureuse avec GIT. Bon je n’ai sans doute pas joué assez avec pour le maîtriser , mais je n’ai jamais eu ce problème avec d’autres VCS certes plus ancien…
Et j’estime que le « coût d’entrée » pour maîtriser ce genre d’outil devrait être léger pour encourager leur utilisation !
Bonjour,
Personnellement je ne suis pas développeur de métier mais sysadmin. Au boulot nous utilisons Git et nous développons selon des procédés « à Giles/SCRUM » et cela se passe très bien, le merge des branches ne cause pas de soucis particuliers, les dev s’en sortent très bien.
Par contre, nous ne bossons pas directement dans la branche master, on créé des branches pour chaque projet puis on merge avec la branche de prod quand tout est bon (tests unitaire, selenium, test de charge…).
Cordialement.
Oui c’est aussi ce que nous avions fait et ça ne s’est pas bien passé du tout.
J’ai même perdu du code! (très mal en fait)
Peut être que vous ne mergiez pas assez souvent ? Ou que vous bossiez trop souvent sur les mêmes fichiers ?!
Quand Git détecte un conflit, ce qui peut bien entendu nous arriver, un petit coup de Meld et tout se règle assez rapidement.