Indika, développeuse fraîchement embauchée, a soumis une pull request sur le projet de son équipe et en a informé son manager Bill. Bill a réagi négativement, la renvoyant au guide des développeurs de son équipe – distinct du guide officiel au niveau entreprise qu'elle avait déjà consulté.

Le guide de Bill était sans équivoque : les branches sont interdites. La fusion est considérée comme une perte de temps et contraire aux principes CI. Les seules opérations git autorisées sont commit, push et pull – apparemment tout le travail doit se faire directement sur la branche principale.

Quand Indika a demandé à une collègue, Elise, si cette règle était sérieuse, celle-ci l'a confirmée mais a aussi révélé le secret de l'équipe : tout le monde utilise régulièrement des branches et des pull requests, mais veille à ce que Bill ne le sache pas. La norme non écrite consiste à cacher cette pratique standard du développement au manager.

Indika a finalement confronté Bill à la cafétéria pour comprendre son raisonnement. Bill s'est appuyé sur vingt ans d'expérience et a argued que les branches créent des points de conflit, laissent le code devenir obsolète et cause aux développeurs de prendre du retard sur leurs coéquipiers. Il a reconnu que les grands projets open-source pourraient bénéficier des branches mais les a rejetées comme des « jouets brillants » inutiles pour une petite équipe interne.

La situation reflète un décalage entre les pratiques établies de développement logiciel et la philosophie idiosyncratique d'un manager, forçant l'équipe à fonctionner selon un processus souterrain non officiel.