it-swarm-eu.dev

Warum nutzt jeder Git zentral?

Ich habe Git in meinen letzten beiden Unternehmen zur Versionskontrolle verwendet. Wie ich gehört habe, verwenden etwa 90% der Unternehmen Git gegenüber anderen Versionskontrollsystemen.

Eines der größten Verkaufsargumente von Git ist, dass es dezentralisiert ist, d. H. Alle Repositorys sind gleich; Es gibt kein zentrales Repository/Quelle der Wahrheit. Dies war ein Feature Linus Torvalds verfochten.

Es scheint jedoch, dass jedes Unternehmen Git zentral verwendet, ähnlich wie man SVN oder CVS verwenden würde. Es gibt immer ein zentrales Repository auf einem Server (normalerweise auf GitHub), von dem die Leute abrufen und auf das sie pushen. Ich habe noch nie (nach meiner zugegebenermaßen begrenzten Erfahrung) Leute gesehen oder gehört, die Git in der wirklich dezentralen Art und Weise verwenden, wie es beabsichtigt war, d. H. Nach Belieben in die Repositories anderer Kollegen zu schieben und zu ziehen.

Meine Fragen sind:

  1. Warum verwenden die Leute in der Praxis keinen verteilten Workflow für Git?
  2. Ist die Fähigkeit, verteilt zu arbeiten, für die moderne Versionskontrolle überhaupt wichtig oder klingt es einfach nur gut?

Bearbeiten

Mir wurde klar, dass ich in meiner ursprünglichen Frage nicht den richtigen Ton gefunden habe. Es klang, als würde ich fragen, warum jemand zentral arbeiten würde, wenn ein verteiltes Versionskontrollsystem (DVCS) so offensichtlich überlegen war. Eigentlich wollte ich sagen: Ich sehe überhaupt keine Vorteile für DVCS . Dennoch höre ich oft Leute, die ihre Überlegenheit predigen, während die reale Welt meiner Ansicht zuzustimmen scheint.

292
gardenhead

Ahh, aber in der Tat sind mit git dezentral!

Vergleichen wir den Vorgänger von git in mindshare, svn. Subversion hatte nur ein "Repo", eine Quelle der Wahrheit. Wenn Sie ein Commit durchgeführt haben, war es ein einzelnes zentrales Repo, zu dem sich auch jeder andere Entwickler verpflichtet hat.

Diese Art funktionierte, führte aber zu zahlreichen Problemen, wobei das größte das gefürchtete Zusammenführungskonflikt war. Es stellte sich heraus, dass diese von ärgerlich bis albtraumhaft zu lösen waren. Und mit einer Quelle der Wahrheit hatten sie die böse Angewohnheit, die Arbeit aller zum Stillstand zu bringen, bis sie gelöst waren. Zusammenführungskonflikte bestehen sicherlich mit git, aber sie sind keine arbeitsstoppenden Ereignisse und lassen sich viel einfacher und schneller lösen. Sie betreffen im Allgemeinen nur die Entwickler, die an den widersprüchlichen Änderungen beteiligt sind, und nicht alle.

Dann gibt es den ganzen Single-Point-of-Failure und die damit verbundenen Probleme. Wenn Ihr zentrales SVN-Repo irgendwie stirbt, sind Sie alle geschraubt, bis es aus dem Backup wiederhergestellt werden kann, und wenn es keine Backups gab, sind Sie alle doppelt geschraubt. Wenn das "zentrale" Git-Repo stirbt, können Sie es aus dem Backup oder sogar von einer der anderen Kopien des Repos wiederherstellen, die sich auf dem CI-Server, den Workstations der Entwickler usw. befinden. Sie können dies genau deshalb tun, weil sie verteilt sind. und jeder Entwickler hat eine erstklassige Kopie des Repos.

Auf der anderen Seite, da Ihr Git-Repo is ein erstklassiges Repo für sich ist, gehen Ihre Commits beim Commit zu Ihrem lokalen Repo. Wenn Sie sie mit anderen oder mit der zentralen Quelle der Wahrheit teilen möchten, müssen Sie dies explizit mit einem Push an eine Fernbedienung tun. Andere Entwickler können diese Änderungen dann nach unten ziehen, wenn es für sie günstig ist, anstatt svn ständig überprüfen zu müssen, um festzustellen, ob jemand etwas getan hat, das sie vermasselt.

Die Tatsache, dass Sie, anstatt direkt an andere Entwickler zu senden, Änderungen indirekt über ein anderes Remote-Repo an diese übertragen, spielt keine große Rolle. Aus unserer Sicht ist es wichtig, dass Ihre lokale Kopie des Repos ein eigenständiges Repo ist. In svn wird die zentrale Quelle der Wahrheit durch das Design des Systems erzwungen. In git hat das System nicht einmal dieses Konzept; Wenn es eine Quelle der Wahrheit gibt, wird dies extern entschieden.

257
Michael Hampton

Wenn Ihr Build-Server (Sie sind mit CI, richtig?) Einen Build erstellt, woher kommt er? Sicher, ein Integrations-Build, von dem Sie argumentieren könnten, benötigt kein "ein echtes Repo", aber sicherlich ein Distributions-Build (d. H. Was Sie dem Kunden geben).

Mit anderen Worten: Fragmentierung. Wenn Sie ein Repo als "das" Repo festlegen und Wächter ernennen, die Pull-Anfragen überprüfen, haben Sie eine einfache Möglichkeit, die Anfrage "Geben Sie mir einen Software-Build" oder "Ich bin neu im Team, wo ist der Code?" Zu erfüllen.

Die Stärke von DVCS ist nicht so sehr der Peer-to-Peer-Aspekt, sondern die Tatsache, dass es hierarchisch ist. Ich ändere meinen Arbeitsbereich und verpflichte mich dann zu lokal. Sobald ich eine Funktion abgeschlossen habe, füge ich meine Commits zusammen und schiebe sie auf meine Fernbedienung. Dann kann jeder meinen vorläufigen Code sehen, Feedback geben usw., bevor ich eine Pull-Anfrage erstelle und ein Projektadministrator sie in das One True-Repo einfügt.

Mit herkömmlichem CVCS verpflichten Sie sich entweder oder Sie tun es nicht. Das ist für einige Workflows in Ordnung (ich verwende beide VCS-Typen für verschiedene Projekte), fällt aber für ein öffentliches oder OSS-Projekt auf den Kopf. Der Schlüssel ist, dass DVCS mehrere Schritte umfasst, die mehr Arbeit bedeuten, aber eine bessere Möglichkeit bieten, Code von Fremden durch einen integrierten Prozess zu integrieren, der eine bessere Übersicht über das, was eingecheckt wird, ermöglicht. Wenn Sie ihn zentral verwenden, können Sie trotzdem haben diesen Goldstandard des aktuellen Standes des Projekts und bieten gleichzeitig einen besseren Mechanismus für die gemeinsame Nutzung von Code.

117
user22815

Ich weiß nicht, wie Sie "alle" definieren, aber mein Team hat "ein zentrales Repo auf einem Server" und auch von Zeit zu Zeit ziehen wir aus den Repos anderer Kollegen, ohne über dieses 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 Repo. Dies geschieht im Allgemeinen, wenn eine Gruppe an einem bestimmten Feature zusammenarbeitet und auf dem Laufenden bleiben möchte, aber 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, alles zu tun, was am bequemsten ist. Wir können je nach Geschmack einen Feature-Zweig veröffentlichen oder nicht.

Aber in über 90% der Fälle gehen wir sicher über das zentrale Repo. Wenn mir eine bestimmte Änderung oder die Arbeit eines bestimmten Kollegen egal ist, ist es bequemer und skalierbarer, "alle Änderungen meiner Kollegen, die im zentralen Repo überprüft wurden", abzurufen, 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 es der einzige verfügbare Workflow ist.

"Verteilt" bedeutet, dass alle Repos in Bezug auf die Software git technisch gleichwertig sind, daraus folgt jedoch nicht, dass sie für Entwickler und unsere Workflows alle gleich wichtig sind. Wenn wir für Clients oder Produktionsserver freigeben, hat das Repo, das wir dafür verwenden, eine andere Bedeutung als ein Repo, das nur von einem Entwickler auf seinem Laptop verwendet wird.

Wenn "wirklich dezentral" bedeutet "es gibt keine speziellen Repos", dann denke ich nicht, dass Linus dies für den Champion bedeutet, da er tatsächlich tut spezielle Repos unterhält, die sind) Wichtiger im großen Schema der Dinge, als ein zufälliger Linux-Klon, den ich gestern erstellt habe und den ich nur verwenden möchte, um einen kleinen Patch zu entwickeln und ihn dann zu löschen, sobald er den Patch akzeptiert hat. git privilegiert sein Repo nicht gegenüber meinem, aber Linus tut privilegiert es. Sein "ist der aktuelle Stand von Linux", meins nicht. Also ändert sich natürlich tendiert um durch Linus zu gehen. Die Stärke von DVCS gegenüber zentralisiertem VCS besteht nicht darin, dass es kein De-facto-Zentrum geben darf, sondern darin, dass Änderungen kein Zentrum durchlaufen müssen, da (wenn es die Konflikte erlauben) jeder etwas zusammenführen kann.

DVCS-Systeme sind auch erzwungen, da sie dezentralisiert sind, um bestimmte praktische Funktionen bereitzustellen, die auf der Tatsache beruhen, dass Sie unbedingt eine vollständige Historie (d. H. Ein Repo) vor Ort haben müssen, um etwas zu tun. Wenn Sie jedoch darüber nachdenken, gibt es keinen fundamentalen Grund, warum Sie kein zentrales VCS mit einem lokalen Cache konfigurieren könnten, der den gesamten Verlauf für schreibgeschützte Vorgänge als veraltet zulässt (ich denke, Perforce hat eine Option für diesen Modus). aber ich habe Perforce noch nie benutzt). Oder Sie können git im Prinzip mit Ihrem .git/ Verzeichnis auf einem remote gemounteten Dateisystem, um die "Funktion" von SVN zu emulieren, dass es nicht funktioniert, wenn Sie keine Netzwerkverbindung haben. Tatsächlich erzwingt DVCS, dass die Rohrleitungen robuster sind, als Sie es mit einem zentralen VCS erreichen können. Dies ist ein (sehr willkommener) Nebeneffekt und hat das DVCS-Design motiviert, aber diese Verteilung der Verantwortung auf der Ebene technisch ist nicht gleichbedeutend mit der vollständigen Dezentralisierung aller menschlichen Verantwortung.

40
Steve Jessop

Das Interessante an der Natur von DVCS ist, wenn andere Leute es auf verteilte Weise verwenden, würden Sie es wahrscheinlich nicht wissen, wenn sie nicht direkt mit Ihnen interagieren. Das einzige, was Sie definitiv sagen können, ist, dass Sie und Ihre direkten Teamkollegen git nicht auf diese Weise verwenden. Dies erfordert keine unternehmensweite Richtlinie. Also werde ich Sie fragen, warum nicht Sie git dezentral verwenden?

Um Ihre Bearbeitung zu beheben, benötigen Sie möglicherweise Erfahrung in der Arbeit mit einer tatsächlich zentralisierten Versionskontrolle, um die Unterschiede zu erkennen, da sie zwar subtil erscheinen, aber allgegenwärtig sind. Dies sind alles Dinge, die mein Team bei der Arbeit tatsächlich tut und die wir nicht tun konnten, als wir VCS zentralisiert hatten:

  • Haben Sie eine sehr kleine Liste von Kernentwicklern mit Commit-Zugriff auf das "zentrale" Repo für jeden Microservice. Alle anderen können mit Gabeln arbeiten und über Pull-Anfragen einreichen.
  • Kann viel häufiger festlegen, normalerweise mehrmals pro Stunde im Vergleich zu ein- oder zweimal pro Tag.
  • Kann Zweige aus irgendeinem Grund erstellen, um sie vorübergehend mit Kollegen zu koordinieren. Drücken Sie darauf und ziehen Sie mehrmals täglich daraus. Ziehen Sie sie dann zusammen, wenn Sie bereit sind, sie mit einer größeren Gruppe zu teilen. Haben Sie eine Vorstellung davon, wie schwierig es ist, die Erlaubnis zum Erstellen eines temporären Zweigs für so etwas in einem herkömmlichen CVCS zu erhalten?

Auf die Gefahr hin, alt zu klingen, weil Sie es gesagt haben, wissen Sie wirklich nicht, wie einfach Sie es haben.

27
Karl Bielefeldt

Ich denke, Ihre Frage kommt von einer (verständlichen) immer verbundenen Denkweise. d. h. Der zentrale "Wahrheit" -CI-Server ist immer (oder fast immer) verfügbar. Während dies in den meisten Umgebungen zutrifft, habe ich in mindestens einer gearbeitet, die weit davon entfernt war.

Ein militärisches Simulationsprojekt, an dem mein Team vor einigen Jahren gearbeitet hat. Alle der Code (wir sprechen von einer Codebasis von> 1 Mrd. USD) musste (per Gesetz/internationalem Abkommen, Männer) in dunklen Anzügen kommen, wenn Sie nicht) auf Maschinen sind physisch isoliert von jeder Internetverbindung. Dies bedeutete die übliche Situation, dass wir jeweils 2 PCs hatten, einen zum Schreiben/Ausführen/Testen des Codes, den anderen für Google-Dinge, zum Abrufen von E-Mails und dergleichen. Und es gab ein lokales Netzwerk innerhalb des Teams dieser Maschinen, das offensichtlich in keiner Weise mit dem Internet verbunden war.

Die "zentrale Quelle der Wahrheit" war eine Maschine auf einer Militärbasis in einem unterirdischen fensterlosen Raum aus Aschenblock (verstärktes Gebäude, Yada-Yada). Diese Maschine auch hatte keine Internetverbindung.

In regelmäßigen Abständen wäre es jemandes Aufgabe, eine Fahrt (physisch) mit dem Git-Repo (das alle unsere Codeänderungen enthält) zur Militärbasis zu transportieren - die mehrere hundert Kilometer entfernt war, wie Sie sich vorstellen können.


Darüber hinaus in sehr großen Systemen, in denen Sie viele Teams haben. Sie haben in der Regel jeweils ein eigenes "zentrales" Repo, das dann auf das eigentliche "zentrale" zentrale Repo (Gottesstufe) zurückgeht. Ich kenne mindestens einen anderen Auftragnehmer, der den gleichen Git-Repo-Dash auf der Festplatte auch mit seinem Code ausgeführt hat.

Wenn Sie etwas in der Größenordnung des Linux-Kernels in Betracht ziehen ... Entwickler senden nicht einfach eine Pull-Anfrage an Linus selbst. Es ist im Wesentlichen eine Hierarchie von Repos - von denen jedes für jemanden/ein Team "zentral" war/ist.

Die getrennte Natur von git bedeutet, dass es in Umgebungen verwendet werden kann, in denen verbunden Modell-Quellcodeverwaltungs-Tools ( dh SVN, z one) konnte nicht verwendet werden - oder konnte nicht so einfach verwendet werden.

19
Tersosauros

Letztendlich bauen Sie ein Produkt. Dieses Produkt repräsentiert Ihren Code zu einem bestimmten Zeitpunkt. Vor diesem Hintergrund muss Ihr Code zusammenwachsen irgendwo. Der natürliche Punkt ist ein CI-Server oder ein zentraler Server, von dem aus das Produkt erstellt wird, und es ist sinnvoll, dass dieser zentrale Punkt ein Git-Repository ist.

18
Bryan Oakley

Der verteilte Aspekt eines DVCS zeigt sich in der Open-Source-Entwicklung ständig in Form von Forking. Zum Beispiel wurden einige der Projekte, zu denen ich beitrage, vom ursprünglichen Autor aufgegeben und haben jetzt eine Reihe von Gabeln, bei denen die Betreuer manchmal bestimmte Funktionen voneinander abziehen. Selbst im Allgemeinen nehmen OSS-Projekte externe Beiträge über Pull-Anfragen entgegen, anstatt zufälligen Personen Push-Zugriff auf das Ground-Truth-Repo zu gewähren.

Dies ist kein sehr häufiger Anwendungsfall beim Erstellen eines konkreten Produkts mit einer bestimmten offiziellen Version, aber in der F/OSS-Welt ist dies die Norm und nicht die Ausnahme.

14
fluffy

Warum nutzt jeder Git zentral?

Wir haben uns nie getroffen, wie kommt es, dass du alle sagst? ;)

Zweitens gibt es weitere Funktionen, die Sie in Git finden, jedoch nicht in CVS oder SVN. Vielleicht nehmen Sie nur an, dass dies die einzige Funktion für alle sein muss. .

Sicher, viele Leute können es zentral verwenden, wie CVS oder SVN. Vergessen Sie jedoch nicht die andere Funktion, die von Natur aus mit einem verteilten VCS geliefert wird: Alle Kopien sind mehr oder weniger "vollständig" (alle Zweige und der vollständige Verlauf sind verfügbar) und alle Zweige können ausgecheckt werden, ohne eine Verbindung zu einem Server herzustellen.

Ich bin der Meinung, dass dies ein weiteres Feature ist, das man nicht vergessen sollte.

Während Sie dies mit Out-of-Box-CVS und SVN nicht tun können, kann Git ohne Probleme zentral wie die vorherigen verwendet werden.

So kann ich meine Änderungen festschreiben, möglicherweise die laufenden Commits zusammenfassen und dann meine Arbeit abrufen und auf den Hauptentwicklungszweig übertragen.

Weitere Funktionen, die mit Git sofort verfügbar sind:

  • commits kryptografisch unterzeichnen
  • neuausrichtung (Neuordnungs- und Squash-Commits; Bearbeitungs-Commits, nicht nur die Nachricht)
  • rosinenpickerei
  • die Geschichte halbieren
  • lokale Filialen und Versteckänderungen (in Wikipedia "Regale" genannt)

Siehe auch diese drei Tabellen in Wikipedia - Vergleich der Versionskontrollsoftware :

Vielleicht ist die dezentrale Methode nicht die einzige Funktion, die die Leute dazu bringt, sie zu verwenden.

  1. Warum verwenden die Leute in der Praxis keinen verteilten Workflow für Git?

Jeder, der zu einem größeren Projekt auf Bitbucked, GitHub usw. beiträgt oder dieses hostet, wird dies genau tun. Die Betreuer behalten das "Haupt" -Repository bei, ein Contributor klont, schreibt fest und sendet dann eine Pull-Anfrage.

In Unternehmen ist selbst bei kleinen Projekten oder Teams ein verteilter Workflow eine Option, wenn sie entweder Module auslagern und nicht möchten, dass externe Mitarbeiter die heiligen Entwicklungszweige ändern, ohne dass ihre Änderungen zuvor überprüft werden.

  1. Ist die Fähigkeit, auf verteilte Weise zu arbeiten, für die moderne Versionskontrolle noch wichtig, ...

Wie immer: es kommt auf die anforderungen an.

Verwenden Sie ein dezentrales VCS, wenn ein Punkt zutrifft:

  • möchten den Verlauf offline festschreiben oder navigieren (d. h. das Submodul in der Berghütte während des Urlaubs fertigstellen)
  • stellen Sie zentrale Repos bereit, möchten Sie jedoch das "wahre" Repository auseinanderhalten, um Änderungen zu überprüfen (d. h. für große Projekte oder verteilte Teams).
  • sie möchten gelegentlich (eine Kopie) der gesamten Historie und der Zweige bereitstellen und gleichzeitig den direkten Zugriff auf das zentrale Repo verhindern (ähnlich dem zweiten).
  • sie möchten etwas versionieren, ohne dies remote speichern oder ein dediziertes Repository einrichten zu müssen (insbesondere bei Git würde ein bloßer git init . ausreichen, um bereit zu sein, etwas zu versionieren).

Es gibt noch mehr, aber vier sollten ausreichen.

... oder klingt es einfach nur gut?

Natürlich klingt es schön - für Anfänger.

9

Flexibilität ist sowohl ein Fluch als auch ein Segen. Und da Git extrem flexibel ist, ist es fast immer weit zu flexibel für die typische Situation. Insbesondere sind die meisten Git-Projekte nicht Linux.

Infolgedessen besteht die kluge Wahl darin, einen Teil dieser theoretischen Flexibilität bei der Implementierung von Git zu entfernen. Theoretisch können Repositorys jeden Graphen bilden, in der Praxis ist die übliche Wahl ein Baum. Wir können die klaren Vorteile anhand der Graphentheorie erkennen: In einem Baum von Repositorys teilen sich zwei beliebige Repositorys genau einen Vorfahren. In einem zufälligen Diagramm existiert die Idee eines Vorfahren nicht einmal!

Ihr Git-Client verwendet jedoch mit ziemlicher Sicherheit standardmäßig das Modell "einzelner Vorfahren". Und Diagramme, in denen Knoten einen einzelnen Vorfahren haben (mit Ausnahme eines Wurzelknotens), sind genau Bäume. Ihr Git-Client selbst verwendet standardmäßig das Baummodell und daher zentralisierte Repositorys.

5
MSalters

Geschäftslogik belohnt einen zentralen Server. Für fast alle realistischen Geschäftsszenarien ist ein zentraler Server ein grundlegendes Merkmal des Workflows.

Nur weil Sie die Fähigkeit haben, DVCS auszuführen, bedeutet dies nicht, dass Ihr primärer Arbeitsablauf DVCS sein muss. Wenn ich git bei der Arbeit benutze, verwenden wir es zentral, mit Ausnahme der seltsamen Fälle, in denen das verteilte Bit wesentlich war, um die Dinge in Bewegung zu halten.

Die verteilte Seite der Dinge ist kompliziert. Normalerweise möchten Sie die Dinge reibungslos und einfach halten. Durch die Verwendung von git stellen Sie jedoch sicher, dass Sie Zugriff auf die verteilte Seite haben, um die schwierigen Situationen zu bewältigen, die später auftreten können.

4
Cort Ammon

Damit ein Mitarbeiter von einem Git-Repo auf meinem Computer abrufen kann, muss ein Git-Daemon als Hintergrundaufgabe auf Root-Ebene ausgeführt werden. Ich bin sehr misstrauisch gegenüber Dämonen, die auf meinem eigenen Computer oder auf meinem von der Firma bereitgestellten Laptop laufen. Die einfachste Lösung ist "NEIN"! Damit ein Mitarbeiter von einem Git-Repo auf meinem Computer abrufen kann, muss auch meine Internetadresse festgelegt werden. Ich reise, arbeite von zu Hause aus und arbeite gelegentlich von meinem Büro aus.

Auf der anderen Seite dauert das VPNing zum Unternehmensstandort und das Verschieben einer Filiale zum zentralen Repo weniger als eine Minute. Ich muss nicht einmal VPN, wenn ich im Büro bin. Meine Mitarbeiter können leicht aus diesem Zweig ziehen.

Auf der dritten Seite ist mein lokales Git-Repo ein voll ausgestattetes Repository. Ich kann neue Arbeit leisten, einen neuen Zweig für experimentelle Arbeit schaffen und die Arbeit zurücksetzen, wenn ich ein Durcheinander mache, selbst wenn ich in einem Flugzeug arbeite, das in einer Höhe von 30.000 Fuß über dem Nirgendwo fliegt. Versuchen Sie dies mit einem zentralen Versionskontrollsystem.

3
David Hammen

Komplexität:

Bei einem zentralen Repository kann dies ein typischer Arbeitsablauf sein

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and Push

Die Komplexität in Bezug auf die Anzahl der Entwickler in O (1).

Wenn stattdessen jeder Entwickler seinen eigenen Hauptzweig hat, wird dies für Entwickler 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Der Peer-to-Peer-Ansatz ist O (N).

Konsistenz:

Überlegen Sie nun, ob es einen Zusammenführungskonflikt zwischen Alices Hauptzweig und Bobs Hauptzweig gibt. Jeder der N Entwickler könnte den Konflikt anders lösen. Ergebnis: Chaos. Es gibt Möglichkeiten, eine eventuelle Konsistenz zu erreichen, aber bis dies passiert, können alle Arten von Entwicklerzeit verschwendet werden.

2

Einfach:

Unternehmen sind zentralisierte Organisationen mit zentralisiertem Workflow.

Jeder Programmierer hat einen Chef und er hat seinen Chef usw. bis zum CTO. CTO ist die ultimative Quelle für technische Wahrheit. Welches Werkzeugunternehmen auch immer verwendet, es muss diese Befehlskette widerspiegeln. Eine Firma ist wie eine Armee - man kann nicht zulassen, dass Privatpersonen einen General überstimmen.

GIT bietet Funktionen, die für Unternehmen nützlich sind (z. B. Pull-Anfragen zur Codeüberprüfung) und die sie allein dazu veranlassen, zu GIT zu wechseln. Der dezentrale Teil ist einfach eine Funktion, die sie nicht benötigen - also ignorieren sie ihn.

Um Ihre Frage zu beantworten: Der verteilte Teil ist in verteilten Umgebungen, z. B. Open Source, in der Tat überlegen. Die Ergebnisse variieren je nachdem, wer spricht. Linus Torvalds ist nicht gerade Ihre Kabinenratte, deshalb sind ihm andere Funktionen von GIT wichtig als für Ihr github-zentriertes Unternehmen.

1
Agent_L