GIT n’est pas magique !

Après un article qui explique “pourquoi GIT c’est mieux que SVN ?“, j’ai jugé qu’il pouvait être intéressant de faire un petit retour sur mon expérience et d’expliquer les bonnes ou mauvaises pratique autour de ce merveilleux logiciel de versionning.

Pourquoi GIT n’est pas magique ?

Certaines personnes pensent que GIT est “magique”. Il permet de merger mieux que SVN c’est donc l’occasion de faire plein de fork ? GIT permet de décentraliser, est-ce une bonne idée de le garder centraliser ? Autant de bonnes questions auquel il est important de répondre.

Comment savoir si vous utilisez mal git ?

• Vous avez plus de 20 branches en cours de développement sur votre serveur GIT
• Votre serveur GIT est centralisé et tout le monde utilise ce même serveur
• Tout le monde a le droit de push
• Aucune personne n’est en charge des merges
• Vous n’avez pas l’habitude de signer.

Si vous vous reconnaissez dans un ou plusieurs de ces choix, il faut revoir votre politique de développement .

TROP de fork TUE le fork.

GIT n’est pas magique et même si il facilite les merges entre les branches il n’est pas “conflict proof”. Certains conflits vont apparaitre c’est obligatoire, et ce n’est pas parce qu’il facilite les merge qu’il faut pour autant ne pas prendre des mesures pour les éviter.

Lorsque l’on décide de développer plusieurs projets en parallèles sur une même base il est bon de définir ce qui va être développé. Il est toujours bon dans une structure d’avoir une personne qui décide des points clés d’un projet et si plusieurs points se rejoignent il faut faire en sorte que les équipes n’effectuent pas le même travail chacun de leur coté ou alors vous risquez irrémédiablement d’avoir des conflits.

Cela peut paraitre “trivial” mais pour autant dans des structures de taille moyenne, il n’y a pas toujours de personnes dédiés à ce genre de coordination. GIT nous oblige ici à avoir un développement discipliné.

Une organisation bien défini

Si vous n’avez qu’un seul serveur GIT pour tout centraliser vous avez fait une grosse erreur. Pourquoi ?

• Si vous avez une équipe ou une personne avec des compétences assez médiocres, comment contrôlerez vous l’intégration de son développement ?
• Quand bien même vous auriez une équipe très compétente, quel est l’intérêt d’avoir tout vos commits centralisé sur un même serveur en permanence ? A part avoir beaucoup trop de branches et beaucoup trop de choses à gérer cela n’est pas très utile. C’est une mauvaise habitude résultant de l’utilisation de SVN

Intéressons nous à  l’organisation du noyau Linux. Si je devais la résumer en une seule phrase de Machiavel “Diviser pour mieux régner”. Si Linus Torvalds a choisit cette organisation ce n’est pas pour rien. C’est un geek et tout bon geek est fainéant.

Il fait confiance à un certains nombre de personnes. Il vérifie de manière ponctuel un certain nombre de patch mais si un patch qu’on lui envoie est signé par 2 ou 3 personnes de confiance il peut l’intégrer sans trop de vérification au noyau Linux.

Dans une entreprise cette attitude serait similaire a un coordinateur qui irait récupérer une branche git définit comme stable et qui ferait une vérification de cette branche avant son intégration. Si ce coordinateur n’a jamais eu de soucis avec le responsable du développement de la branche, il peut juste effectuer des vérifications sommaire mais là nous rentrons plus dans une relation de confiance et dans le relationnel entre les personnes de l’équipe.

Dans une grosse structure on pourrait voir ainsi 1, 2, 3, voir même 4 niveaux de hiérarchie entre le développeur et le “code keeper”. Le plus haut niveau n’a pas a se soucier des problèmes de développement, il a juste a valider la version finale qui sera intégrer dans le GIT. A contrario, le bas niveau n’a pas à se soucier de l’integration, il respecte juste un certain nombre de règles et développe son application.

Et si on pense que cela ne sert à rien ?

Si il n’y a aucune validation on peut se retrouver dans des cas dramatiques.

Un merge farfelus d’une branche en test dans un développement pour ne pas se prendre la tête et faire un raccourcis, des hotfix sur le noyau dans plusieurs branches, aucun suivis des branches upstream ou encore des merges avec une strategy “-s ours” sans vérification. L’intégration d’une branche “MAUDITE” peut devenir un vrai casse tête voir même impossible.

Au hasard les conséquences peuvent être:

• De nombreux conflits
• L’intégration de code “instable” par merge d’une branche déjà mergé avec une autre branche instable
• Rendre le code moins performant.

Bien sûr vous avez pu mettre un certain nombre d’indicateur comme des tests unitaires, des coverages reports mais il faut dans tout les cas avoir une organisation solide.

Cas pratique: la traversée du désert

Prenons un cas pratique que j’ai déjà eu l’occasion de voir. Ce cas j’aime l’appeler “la traversée du désert”.

Prenez un développeur, donnez lui une tâche et laissez le faire son fork. Il revient 3 mois après avec un développement qui a modifié votre noyau de base, qui n’a pas suivis les évolutions de l’upstream et qui soit dit en passant a sûrement réinventé la roue carrée. Résultat ? 3 mois de travail de perdu. Son code peut être considéré comme inutilisable.

L’image de traversée du désert montre bien l’image de ce développeur qui part seul sans radio avec une mission sommairement posé sur un bout de papier. Son chef de projet confiant pense que GIT arrivera comme un grand a merger ce qu’il “dénichera”. Il se trompe, cela ne changera rien.

Si vous deviez retenir que quelques regles ?

With great power comes great responsibility

1. Définissez une organisation.
2. Formez les personnes responsables aux différents enjeux.
3. Instaurez un climat de confiance entre les différents niveaux de votre pyramide.
4. Ne donnez pas des “pouvoirs” à des gens qui ne les maitrisent pas.
5. Définissez des règles pour les modifications de parties communes a tout les projets.

Ces règles pourraient être tout aussi utile pour un développement sous SVN mais le fait de faire des “fork” accentuent ces problèmes car les développeurs peuvent vite être isolé et leurs erreurs peuvent être detecté moins vite et avoir un plus gros impact sur le long terme.

Pour conclure

GIT est un outil puissant avec une grande liberté d’action. Il peut vous apportez beaucoup mais il faut bien comprendre son fonctionnement. Autant pour l’utilisateur néophyte qui fait un fork de Ruby on Rails pour rajouter une fonction, son utilisation est simple; autant pour la gestion de très gros projet, son utilisation peut être contre productive si vous n’avez pas une organisation bien structurée.

Si vous prenez la décision de changer de logiciel de versionning est d’adopter une méthode plus agile, plus souple, retenez bien cela ne se traduit pas que dans les logiciels que vous utilisez mais aussi dans l’utilisation que vous en faite.

Les mentalités sont encore habitués a un système de versioning centralisé avec un impact direct sur le développement. Avec GIT vous entrez dans des méthodes de développement sur le long terme où il faut savoir anticiper les problèmes avant de les laisser germer.