Warum sich der Graphite-Entwickler Greg Foster dafür interessierte
- Er startete das Graphite-Projekt, inspiriert von internen Tools bei Facebook
- Nachdem ehemalige Facebook-Kollegen ihm Mercurial und den Workflow mit „stacked diffs“ vorgestellt hatten, beschloss er, dies für GitHub-Entwickler einzuführen, und baute schließlich eine CLI, die Ideen aus Hg in Git integriert
- Warum entschied sich Facebook für Mercurial statt Git und baute darauf einen eigenen Workflow auf?
- Auch Google verwendet Git nicht, aber das liegt daran, dass Googles Engineering Git um mehr als fünf Jahre voraus war
- Facebook hingegen wurde 2004 gegründet, also ungefähr zu der Zeit, als Git entstand, und als Facebook anfing, Source-Control-Tools ernsthaft zu evaluieren, war Git populärer als Mercurial
- Warum also verwendet Facebook kein Git?
- Seiner Ansicht nach sähe die Engineering-Welt heute anders aus, wenn Facebook Git eingeführt und Anfang der 2010er Jahre dazu beigetragen hätte
- Git wäre möglicherweise benutzerfreundlicher geworden und würde Stacked Changes nativ unterstützen
- Unternehmen wie Uber und Pinterest, die von frühen Facebook-Mitarbeitern gegründet wurden, hätten vielleicht Git und GitHub statt Mercurial als Source Control verwendet, was in den letzten zehn Jahren zu einem weniger fragmentierten Ökosystem geführt hätte
- Facebook blieb jedoch nicht bei Git (für das zentrale Monorepo). Stattdessen setzte das Unternehmen für die Versionsverwaltung auf Mercurial und ergänzte es nach und nach um eigene Tools
- Er stieß auf den Facebook-Beitrag Scaling Mercurial at Facebook
- Der Artikel ist zehn Jahre alt, und über einige YouTube-Videos kam er später zu der Antwort: „wegen der Performance“
- Er wollte aber tiefer einsteigen und hören, wie die damaligen Entscheidungsträger gedacht haben, und fragte deshalb zwei Ingenieure, die am Mercurial-Migrationsprojekt beteiligt waren
- Auf Basis informeller Gespräche mit ihnen hat er diese Inhalte zusammengefasst
Warum Facebook Git aufgab und zu Mercurial wechselte
- Facebook nutzte anfangs Git, begann aber um 2012 mit Performance-Problemen zu kämpfen, als die Codebasis stark anwuchs
- Der Datei-„stat-ing“-Prozess von Git wurde zum Flaschenhals, und die Ausführung grundlegender Git-Befehle dauerte mehr als 45 Minuten
- Die Git-Maintainer waren bei den Problemen von Facebook mit extrem großen Repositories nicht besonders kooperativ und empfahlen stattdessen, das Repository aufzuteilen
Welche Alternativen in Betracht gezogen wurden
- 2012 gab es nicht viele Alternativen zu Git, und Facebook prüfte zwar Closed-Source-Lösungen wie Perforce, stieß dabei aber auf technische Probleme
- Mercurial bot eine ähnliche Performance wie Git, hatte aber eine sauberere Architektur und bessere Erweiterbarkeit
- Das Facebook-Team nahm an einem Mercurial-Hackathon teil und war von der Erweiterbarkeit von Mercurial und der Offenheit der Community beeindruckt
Die Migration der gesamten Engineering-Organisation
- Um den Rest des Unternehmens zu überzeugen, ordnete das Facebook-Team Befehle und Workflows zwischen Git und Mercurial einander zu und nahm sich Zeit, die Bedenken der Entwickler anzuhören
- Die Migration wurde sorgfältig durchgeführt, und am Ende wechselte Facebook zu Mercurial
- Facebook trug zur Verbesserung der Performance von Mercurial bei und ermöglichte mit „stacked diffs“ unter anderem die Parallelisierung von Code Reviews
Abschließende Gedanken
- Diese Geschichte erinnert daran, dass „viele wichtige technische Entscheidungen nicht von Technik, sondern von Menschen getrieben werden“
- Facebook entschied sich nicht für Mercurial, weil es performanter als Git war, sondern weil die Zusammenarbeit mit den Mercurial-Maintainern offener war
- Beim Überzeugen der gesamten Engineering-Organisation ging es nicht darum, dass eine Technologie der anderen überlegen war, sondern darum, dass „durchdachte Kommunikation“ entscheidend ist
- Hervorgehoben wird, dass „Kommunikation und Freundlichkeit“ in der Welt der Entwicklerwerkzeuge wichtige Werte sind
2 Kommentare
Da muss ich an den Satz eines Bekannten denken: „Um Kunden zu überzeugen, muss man zum Rückenkratzer werden.“
Es muss weder extrem scharf noch extrem schnell noch besonders bequem noch besonders teuer sein — wenn es genau die Stelle kratzen kann, die gewünscht ist, dann ist genau das der Service, den der Kunde will, haha.
Da Git von Linus Torvalds zur Verwaltung des Linux-Quellcodes entwickelt wurde, denke ich, dass es zwangsläufig einige Punkte gab, bei denen keine Kompromisse möglich waren.
Der Kern des abschließenden Gedankens klingt für mich so, als sei Git schlecht, weil es nicht auf die Anforderungen von Facebook gehört habe und Kommunikation sowie Entgegenkommen nicht wichtig genommen habe; ich denke jedoch, dass sich ihre grundsätzlichen Ausrichtungen in vielerlei Hinsicht einfach unterschieden haben.
Wenn man es umgekehrt betrachtet, hätte Facebook auch die von Git empfohlene Aufteilung des Repositorys akzeptieren und umsetzen können. Es war nur eine Form von Entgegenkommen, die sie selbst nicht wollten.