Pourquoi git me hérisse le poil
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.
