Indika, eine neu eingestellte Entwicklerin, reichte einen Pull Request für das Projekt ihres Teams ein und erwähnte ihn ihrem Manager Bill. Bill reagierte ablehnend und verwies sie auf sein internes Entwicklerhandbuch – nicht das offizielle, unternehmensweite Handbuch, das sie bereits gelesen hatte.

Bills Richtlinie war eindeutig: Branching ist verboten. Merging wird als Zeitverschwendung und gegen CI-Prinzipien verstoßend eingestuft. Die einzigen erlaubten Git-Operationen sind Commit, Push und Pull – offenbar soll jede Arbeit direkt auf dem Main-Branch erfolgen.

Als Indika eine Kollegin, Elise, fragte, ob diese Regel ernst gemeint sei, bestätigte diese es – offenbarte aber auch das Geheimnis des Teams: Alle nutzen regelmäßig Branches und Pull Requests, sorgen aber dafür, dass Bill davon nichts erfährt. Die ungeschriebene Norm lautet, diese Standardentwicklungspraxis vor dem Manager zu verbergen.

Indika konfrontierte Bill schließlich in der Küche, um seine Begründung zu verstehen. Bill berief sich auf zwanzig Jahre Erfahrung und argumentierte, dass Branches Konfliktpunkte schaffen, Code veralten lassen und Entwickler hinter ihre Teammates zurückfallen. Er gestand zu, dass große Open-Source-Projekte von Branches profitieren könnten, lehnte sie aber als unnötige "glänzende Spielzeuge" für ein kleines internes Team ab.

Die Situation zeigt eine Kluft zwischen etablierten Softwareentwicklungspraktiken und der idiosynkratischen Philosophie eines Managers und zwingt das Team, unter einem inoffiziellen Schattenprozess zu arbeiten.