Hello,
Depuis quelque temps, j’ai un petit service rigolo qui tourne sur mon VPS.
Si vous ne savez pas ce qu’est un gestionnaire de version, ne perdez pas votre temps à lire la suite, cela ne vous intéressera probablement pas.
De façon à ce que vous ayez une idée claire de la chose, je pense qu’il est pertinent de commencer par résumer la naissance de ce projet. Revenons-donc un mois en arrière.
Il y a donc environ un mois, j’étais en train de m’amuser à contribuer au développement de ZdS, et on avait des petits problèmes de PRs (Pull Request, des propositions de patch dans le jargon de GitHub). C’était une période où on pouvait ouvrir et fermer pas mal de PRs en une journée, et certaines d’entre elles pouvaient être très grosses comme celle de la réécriture de l’implémentation du zmarkdown.
On arrive vite à un moment où tout le monde ne peut pas suivre ce que fait tout le monde, et se retrouve vite face à des problèmes de conflits assez traîtres.
Voici un petit scénario qui m’est arrivé : J’avais fais une PR
retirant une balise <div> du gros template de base du site qui
englobait tout le menu principal. Du coup, j’avais réindenté tout le
contenu de cette balise, en retirant quatre espaces au début de chaque
ligne. Ça faisait plusieurs centaines de lignes de modifiées. Pendant
ce temps, victor, travaillant sur la PR de zmarkdown, avait modifié
aussi (plus légèrement) le même fichier. Jusqu’à ce moment, personne
ne s’est rendu compte que ces PRs modifiant les mêmes lignes du code
ne peuvent pas être mergée sans résoudre manuellement le conflit. Et
ma PR a été mergée en premier : Paf, on ne peut plus merger celle de
zmarkdown alors que cette dernière était la plus urgente !
Bon, j’ai résolu ces conflits (un peu à l’arrache) sans trop tarder, mais qu’est-ce qui se serait passé si je m’étais absenté pendant une semaine ? Ça aurait stressé toute l’équipe pour pas grand-chose, et des gens auraient corrigé des conflits dans du code qu’ils ne connaissent pas forcément très bien (c’est une très bonne manière d’introduire des bugs).
Du coup, suite à une petite discussion avec victor sur IRC, cette idée
de détecter les conflits entre les PRs à l’avance a murie un peu dans
ma tête, et j’ai donc écrit un petit prototype vite fait. Le principe
est simple : On a un cron qui, toutes les 5 minutes, essaye de merger
toutes les PRs entre elles. Les résultats de chaque git merge sont
archivés, et on construit une belle matrice où les cases blanches
veulent dire “pas de conflit”, et les cases roses ou rouges veulent
dire “conflit”. Le numéro dans ces dernières indique le nombre de
lignes entrant en conflit.
Quand on clique sur une case, on accède à un détail du git merge.
Notez qu’il y a des numéros de commit dans l’URL, et non des noms de branche : C’est parce que les branches sont muables, alors que les commits ne le sont pas. Alors que la matrice est mise-à-jour fréquemment, chaque résultat de merge est archivé et jamais supprimé.
Sur la même page, vous pouvez voir un détail des fichiers entrant en
conflit pour chaque git merge ayant échoué.
Qu’en pensez vous ? Je vous présente ça vu que des gens sur IRC trouvent ça cool. J’attends vos suggestions, vos critiques et vos questions. On m’as parlé d’idées de dingue comme faire une vraie intégration à GitHub (et pourquoi pas GitLab et Gogs), mais j’ai d’abord envie d’être certain que ce projet a un intérêt avant de faire quelque chose de plus compliqué que ce prototype.
Et évidemment, c’est open-source.
Voilà, c’était un peu long, désolé 
) 
