Ich weiß nicht , wie Sie „jeden“ definieren, aber mein Team hat „eine zentrale Repo auf einem Server“ und auch von Zeit zu Zeit , die wir von anderen Kollegen repos ziehen , ohne über diese zentrale Repo zu gehen. Wenn wir dies tun, gehen wir immer noch über einen Server, weil wir uns dafür entscheiden, keine Patches über den Ort per E-Mail zu versenden, sondern nicht über das zentrale Repository. Dies ist in der Regel der Fall, wenn eine Gruppe an einem bestimmten Feature zusammenarbeitet und auf dem neuesten Stand bleiben möchte, jedoch noch kein Interesse daran hat, das Feature für alle zu veröffentlichen. Da wir keine geheimen Siloarbeiter sind, halten diese Situationen natürlich nicht lange an, aber DVCS bietet die Flexibilität, das zu tun, was am bequemsten ist. Wir können einen Feature-Zweig veröffentlichen oder nicht, je nach Geschmack.
Aber in mehr als 90% der Fälle gehen wir sicher über das zentrale Repo. Wenn ich mich nicht für eine bestimmte Änderung oder die Arbeit eines bestimmten Kollegen interessiere, ist es bequemer und besser skalierbar, "alle Änderungen meiner Kollegen, die im zentralen Repo überprüft wurden" zu übernehmen, anstatt Änderungen von jedem von N separat abzurufen Kollegen. DVCS versucht nicht zu verhindern, dass "Pull from Main Repo" der häufigste Workflow ist, sondern, dass er der einzige verfügbare Workflow ist.
"Distributed" bedeutet, dass alle Repos in gitBezug auf die Software technisch gleichwertig sind , jedoch nicht, dass sie für Entwickler und unsere Workflows gleich wichtig sind. Wenn wir an Clients oder Produktionsserver freigeben, hat das Repo, das wir verwenden, eine andere Bedeutung als ein Repo, das nur von einem Entwickler auf seinem Laptop verwendet wird.
Wenn „wirklich dezentrale“ bedeutet „gibt es keine spezielle repos“ , dann glaube ich nicht , das ist , was Linus bedeutet Meister, da er in der Tat nicht hält spezielle repos , die sind wichtiger in dem großen Plan der Dinge, als ist Ein zufälliger Klon von Linux, den ich gestern gemacht habe und der nur dazu verwendet werden soll, einen kleinen Patch zu entwickeln und ihn dann zu löschen, sobald er den Patch akzeptiert hat. githat keinen Vorzug für sein Repo gegenüber meinem, aber Linus hat Vorzug dafür. Sein "ist der aktuelle Stand von Linux", meins nicht. Veränderungen neigen also natürlich dazudurch Linus gehen. Die Stärke von DVCS gegenüber zentralisiertem VCS ist nicht, dass es kein De-facto-Zentrum geben darf, sondern dass Änderungen kein Zentrum durchlaufen müssen, da (sofern Konflikte dies zulassen) jeder etwas zusammenführen kann.
DVCS-Systeme sind auch gezwungen , da sie dezentralisiert sind, bestimmte praktische Funktionen bereitzustellen, die darauf beruhen, dass Sie unbedingt eine vollständige Historie (dh ein Repo) vor Ort haben müssen, um irgendetwas zu tun. Aber wenn Sie darüber nachdenken, gibt es keinen fundamentalen Grund, warum Sie ein zentrales VCS mit einem lokalen Cache nicht konfigurieren können, der den gesamten Verlauf für schreibgeschützte Vorgänge auf dem neuesten Stand hält. (Ich denke, Perforce hat eine Option für diesen Modus.) aber ich habe noch nie Perforce verwendet). Oder prinzipiell könntest du das gitmit deinem konfigurieren.git/Verzeichnis auf einem remote gemounteten Dateisystem, um die "Funktion" von SVN zu emulieren, die nicht funktioniert, wenn Sie keine Netzwerkverbindung haben. Tatsächlich erzwingt DVCS, dass die Rohrleitungen robuster sind, als Sie es in einem zentralen VCS können. Dies ist ein (sehr willkommener) Nebeneffekt und hat zur Motivation des DVCS-Designs beigetragen, aber diese Aufteilung der Verantwortung auf technischer Ebene ist nicht dasselbe wie die vollständige Dezentralisierung der gesamten menschlichen Verantwortung.