Indika, una desarrolladora recién contratada, envió un pull request en el proyecto de su equipo y lo mencionó a su manager Bill. Bill reaccionó negativamente, refiriéndola a la guía interna de desarrolladores de su equipo – distinta de la guía oficial de la empresa que ya había leído.

La guía de Bill era inequívoca: las ramas están prohibidas. La fusión se considera una pérdida de tiempo y contraria a los principios de CI. Las únicas operaciones git permitidas son commit, push y pull – aparentemente todo el trabajo debe realizarse directamente en la rama principal.

Cuando Indika preguntó a una colega, Elise, si esta regla era seria, ella la confirmó pero también reveló el secreto del equipo: todos utilizan regularmente ramas y pull requests, pero se aseguran de que Bill no lo sepa. La norma no escrita es ocultar esta práctica estándar de desarrollo al manager.

Indika finalmente confrontó a Bill en la cafetería para entender su razonamiento. Bill citó veinte años de experiencia y argumentó que las ramas crean puntos de conflicto, dejan que el código se vuelva obsoleto y causan que los desarrolladores se queden atrás de sus compañeros. Reconoció que los grandes proyectos de código abierto podrían beneficiarse de las ramas pero las rechazó como "juguetes brillantes" innecesarios para un pequeño equipo interno.

La situación refleja una desconexión entre las prácticas establecidas de ingeniería de software y la filosofía idiosincrásica de un manager, obligando al equipo a funcionar bajo un proceso paralelo no oficial.