Warum verwendet jeder Git zentral?

289

Ich habe Git in meinen letzten beiden Unternehmen für die Versionskontrolle verwendet. Wie ich gehört habe, verwenden ungefähr 90% der Unternehmen Git gegenüber anderen Versionskontrollsystemen.

Eines der größten Verkaufsargumente von Git ist, dass es dezentralisiert ist, dh alle Repositorys sind gleich. Es gibt kein zentrales Repository / Quelle der Wahrheit. Dies war ein Feature, für das sich Linus Torvalds einsetzte .

Aber es scheint, dass jedes Unternehmen Git zentral verwendet, ähnlich wie man SVN oder CVS verwendet. Es gibt immer ein zentrales Repository auf einem Server (in der Regel auf GitHub), von dem die Benutzer abrufen und auf den sie pushen. Ich habe (nach meiner zugegebenermaßen eingeschränkten Erfahrung) noch nie jemanden gesehen oder gehört, der Git auf die wirklich dezentrale Art und Weise verwendet, wie es beabsichtigt war, dh indem er die Repositorys anderer Kollegen nach Belieben schob und zu diesen zog.

Meine Fragen sind:

  1. Warum verwenden die Leute in der Praxis keinen verteilten Workflow für Git?
  2. Ist das verteilte Arbeiten für die moderne Versionskontrolle überhaupt wichtig oder klingt es nur gut?

Bearbeiten

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

Gartenkopf
quelle
31
Ich fühle genau so und verstehe das nicht.
Snoop
57
Persönlich kenne ich nur keine Anwendungsfälle für mehrere Fernbedienungen, außer Gabeln zum Erstellen von PRs für die Hauptfernbedienung. Das verteilte Ding ist immer noch nützlich, weil es bedeutet, dass ich eine vollständige Historie auf meinem Computer bekomme, ohne mit dem Netzwerk sprechen zu müssen, und ich kann offline arbeiten, wenn ich wirklich will, und es ist viel einfacher, von einem Online-Repo-Host auf einen zu migrieren Ein weiterer. Was genau denken Sie, wenn Sie von einem "verteilten Workflow" sprechen?
Ixrec
43
Ich bin ziemlich sicher, dass Torvalds von Anfang an eine "Quelle der Wahrheit" für das Linux-Kernel-Repository haben wollte.
Steven Burnap
67
Letztlich Software selbst ist zentralisiert. Kunden kaufen keine Filialen oder Fernbedienungen, sondern ein fertiges, zusammengestelltes Produkt. Es muss immer einen zentralen Weg nach vorne geben.
Brandon
37
Für mich ist Gits "Dezentralität" eines der am wenigsten wichtigen Merkmale, die es empfehlen. Die Möglichkeit, häufige Commits und Rollbacks vor Ort durchzuführen, ohne andere zu beeinträchtigen, oder leistungsstarke Techniken wie das erneute Basieren sind der entscheidende Faktor in meinem Workflow. Es ist möglich (in der Tat wahrscheinlich), dass all dies durch die Dezentralisierung ermöglicht wird, aber das "D" in DVCS ist für mich selbst nicht so wichtig.
Jay

Antworten:

257

Ahh, aber in der Tat Sie sind mit git in dezentral!

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

Dies funktionierte, führte jedoch zu zahlreichen Problemen, wobei das größte der gefürchtete Zusammenführungskonflikt war . Es stellte sich heraus, dass diese Probleme 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 zwar mit git, sie sind jedoch keine arbeitsunterbrechenden 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-Repository irgendwie ausfällt, sind Sie alle geschraubt, bis es aus dem Backup wiederhergestellt werden kann, und wenn es keine Backups gab, sind Sie alle doppelt geschraubt. Aber wenn das "zentrale" Git-Repo ausfällt, können Sie es aus dem Backup oder sogar von einer der anderen Kopien des Repos wiederherstellen, die sich auf dem CI-Server, auf den Workstations der Entwickler usw. befinden. Sie können dies genau tun, weil sie verteilt sind. und jeder Entwickler hat eine erstklassige Kopie des Repos.

Auf der anderen Seite, da Ihre git Repo ist eine First-Class - Repo in seinem eigenen Recht, wenn Sie sich verpflichten, Ihre Commits zu Ihrem lokalen Repo gehen. Wenn Sie sie mit anderen teilen möchten oder an die zentrale Quelle der Wahrheit, müssen Sie dies explizit mit einem Push an eine Fernbedienung tun. Andere Entwickler können diese Änderungen dann abrufen, wenn es für sie bequem ist, anstatt svn ständig überprüfen zu müssen, um festzustellen, ob jemand etwas getan hat, das sie durcheinander bringt.

Die Tatsache, dass Sie Änderungen nicht direkt an andere Entwickler , sondern indirekt über ein anderes Remote-Repo ü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.

Michael Hampton
quelle
15
SVN-Zusammenführungen wirken sich auch nur auf die Entwickler aus, die an widersprüchlichen Änderungen beteiligt sind. Ein Commit schafft es in das Repo, keine widersprüchliche Zusammenführung kann in das Repo gehen, bis die Konflikte gelöst sind (Sie können auch ein Commit parallel zu einem separaten Zweig / Pfad durchführen, aber das ist jetzt kein Konflikt, oder?)
Ben Voigt
30
Wenn ein zentraler Server vorhanden ist, besteht der Hauptunterschied darin, dass GIT die fortlaufende lokale Versionierung bei ausgefallenem Netzwerk zulässt und SVN nicht (einige andere Versionskontrollsysteme sind sogar noch schlechter und stellen die gesamte Arbeit ein, wenn das Netzwerk nicht erreichbar ist , weil Sie erst dann eine Datei ändern können, wenn Sie sie ausgecheckt haben).
Ben Voigt
17
@BenVoigt Oh, die Arbeit hört auf. Denken Sie daran, dass Sie svn upmit dem Repo auf dem neuesten Stand sein müssen, bevor Sie einchecken können. Wenn andere weiterhin einchecken, während Sie versuchen, Zusammenführungskonflikte zu lösen, und Ihnen einen weiteren Satz von Zusammenführungskonflikten anbieten, können Sie dies entweder beenden oder du verlierst, was von deiner geistigen Gesundheit übrig ist.
Michael Hampton
21
Nein, die Mitarbeiter können sich definitiv weiterhin auf den Zweig festlegen, aus dem Sie Änderungen zusammenführen, ohne Ihren Workflow zu unterbrechen.
Ben Voigt
29
Ben hat recht. Ein SVN-Repo, das ordnungsgemäß verwaltet und von einem Team verwendet wird, das in der Entwicklung von Software geschult wurde, sollte effektiv niemals Konflikte auf dem Stamm zusammenführen. Sie erhalten sie nur, wenn jemand etwas falsch gemacht hat und gefeuert werden muss (: P). inb4 ist einfacher, wenn Sie die Benutzer nicht in den Umgang mit ihren Werkzeugen einweisen müssen. Ja, es gibt viel mehr über Git zu lehren als über SVN!
Leichtigkeitsrennen im Orbit
118

Wenn Ihr Build - Server (Sie sind mit CI, oder?) Ein Build erzeugt, wo sie zieht es aus? Sicher, ein Integrations-Build, von dem Sie argumentieren könnten, benötigt kein "One True Repo", aber sicherlich ein Distributions-Build (dh das, was Sie dem Kunden geben).

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

Die Stärke von DVCS ist weniger der Peer-to-Peer-Aspekt, sondern die Tatsache, dass es hierarchisch ist . Ich ändere meinen Arbeitsbereich und begebe 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 usw. geben, bevor ich eine Pull-Anfrage erstelle und ein Projektadministrator sie in das One True-Repo einbindet.

Mit herkömmlichem CVCS legen Sie entweder fest oder nicht. Für einige Workflows ist das in Ordnung (ich verwende beide VCS-Typen für verschiedene Projekte), für ein öffentliches Projekt oder ein OSS-Projekt ist das jedoch offensichtlich. Der Schlüssel ist, dass DVCS mehrere Schritte umfasst, die mehr Arbeit erfordern, 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 es zentral verwenden, können Sie es dennoch Sie verfügen über den Goldstandard des aktuellen Projektstatus und bieten gleichzeitig einen besseren Mechanismus für die gemeinsame Nutzung von Code.


quelle
2
Insgesamt eine gute Antwort, aber ich bin mir ziemlich sicher, dass Git vor Continuous Integration weit verbreitet war. Unser Team verwendet übrigens CI, danke für die Überprüfung: D.
Gardenhead
5
@gardenhead: Sie haben den Punkt übersehen: Dasselbe Argument gilt, wenn die Integration manuell erstellt wird. "CI" ist nur eine Automatisierung für einen Prozess, der viel älter als Git ist.
Doc Brown
25
"Jeder kann meinen vorläufigen Code sehen" - und er kann auch Ihren vorläufigen Code abrufen, ihn mit seinem vorläufigen Code zusammenführen und die Tests ausführen. Dies ist ein Problem in zentralisierten VCS, da Verzweigungen und Änderungen in der One True Copy erforderlich sind. Bei der Verteilung konfigurieren Sie einfach zusätzliche Fernbedienungen und beginnen dann mit dem Zusammenführen, Patchen und Auswählen von Kirschen. Sie können nachverfolgen, was Sie getan haben, aber niemand anderes muss jemals nachsehen, was Sie vorhaben, es sei denn, Sie veröffentlichen sie. Im Allgemeinen empfehle ich, dass niemand DVCS für sinnlos erklären sollte, bis er SVN tatsächlich für ein großes Projekt verwendet hat ...
Steve Jessop,
9
Weil es keinen "echten Build" des Linux-Kernels gibt. Da es jeder selbst baut, ist das Repo von Linus nicht kanonischer als das von anderen. Wenn Sie ein Produkt verkaufen, das nicht so gut funktioniert.
Miles Budnek
2
@ Superbest: Ein Großteil (wenn nicht alles) des Designs von Git basierte auf Bitkeeper. Git wurde erstellt, nachdem die Linux-Bitkeeper-Kontroverse implodiert war.
Whatsisname
40

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.

Steve Jessop
quelle
7
Sie sind technisch äquivalent, sozial nicht äquivalent.
curiousdannii
3
Das Versenden von Patches per E-Mail ist ziemlich schmerzlos. Verwenden Sie einfach git format-patch und dann git send-email , falls jemand darüber nachdenkt . Wollte ich nicht mit Githubs Zugangskontrollen herumspielen und es war sehr einfach, dann hat doch jeder eine E-Mail.
Rudolf Olah
1
"Muss unbedingt eine vollständige [...] Geschichte vor Ort haben, um etwas zu tun" - nicht wahr; moderne DSCMs unterstützen partielle Repos ("shallow checkouts" in bzr-Begriffen, "shallow clones" in git-Begriffen).
Charles Duffy
27

Das Interessante an der Natur von DVCS ist, dass Sie es wahrscheinlich nicht wissen, wenn andere Leute es auf verteilte Weise verwenden, es sei denn, sie interagieren direkt mit Ihnen. 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 dich fragen, warum benutzt du git nicht dezentral?

Um Ihre Bearbeitung zu bearbeiten, benötigen Sie möglicherweise einige Erfahrung in der Arbeit mit einer tatsächlichen zentralisierten Versionskontrolle, um die Unterschiede zu erkennen. Dies sind alles Dinge, die mein Team bei der Arbeit macht, als wir VCS zentralisiert hatten:

  • Habe eine sehr kleine Liste von Core-Entwicklern mit Commit-Zugriff auf das "zentrale" Repo für jeden Microservice. Alle anderen können aus Gabeln arbeiten und über Pull-Requests einreichen.
  • Kann sich viel häufiger verpflichten, normalerweise mehrmals pro Stunde im Vergleich zu ein- oder zweimal pro Tag.
  • Sie können Zweige aus beliebigen Gründen erstellen, um sich vorübergehend mit Kollegen zu koordinieren. Sie können mehrmals am Tag darauf drücken und daran ziehen und sie dann zerquetschen, wenn Sie bereit sind, sie mit einer größeren Gruppe zu teilen. Wissen Sie, wie schwierig es ist, in einem herkömmlichen CVCS die Erlaubnis zum Erstellen eines temporären Zweigs für so etwas zu erhalten?

Auf die Gefahr, alt zu klingen, weil man es sagt, weiß man wirklich nicht, wie einfach man es hat.

Karl Bielefeldt
quelle
1
Die Frage, wie schwierig es ist, in einem herkömmlichen CVCS einen Zweig zu erstellen, hängt ganz von der Politik ab: Ich arbeite zufällig mit einem vorgelagerten SVN-Repo (natürlich über einen git-svn-Klon!), Und ich habe das Recht, jeden Zweig I zu erstellen wollen, obwohl es ein ziemlich großes Projekt ist. Es ist mir nur untersagt, bestimmte Integrationszweige zu berühren, geschweige denn den Kofferraum, ohne vorher mit meinen Vorgesetzten zu sprechen. Andere Unternehmen haben möglicherweise andere Richtlinien, die möglicherweise restriktiver sind, dies muss jedoch keinesfalls der Fall sein.
cmaster
7
Du hast recht, ich weiß nicht, wie einfach ich es habe. Ich wünschte, ich wäre in den Tagen der SVN-Dominanz dabei gewesen, um zu schätzen, wie weit wir gekommen sind. Als ein sehr junger Softwareentwickler stelle ich fest, dass sich dasselbe Muster ziemlich oft wiederholt: Je erfahrener Entwickler mir sagen, dass die alte Art, etwas zu tun, schlecht war und diese neue Art / Technologie viel einfacher ist. Aber ich muss nur ihr Wort dafür nehmen; Ich kann die Vorteile nie wirklich einschätzen. Ich fand es immer schwierig, diese Dissonanz zu überwinden.
Gardenhead
1
@gardenhead du kannst immer dein eigenes SVN-Repo erstellen und versuchen, es zu brechen;) (und merke, wie viel schwieriger es ist, ein Git-Repo zu erstellen und es zu klonen ...) - Ein weiteres wichtiges Feature, das mir aufgefallen ist (zumindest in Insbesondere in Unternehmensumgebungen) ist die gemeinsame Nutzung von Dateien entweder etwas umständlich oder erfolgt so, dass Repositorys überlastet werden (z. B. weil der Virenscanner ein Netzwerklaufwerk sperrt).
Wayne Werner
4
@gardenhead: gut, sich glücklich schätzen , dass Sie in einem Legacy - Projekt nicht stecken, mit alten Software - Entwickler , die Sie erzählen die alte Art und Weise , Dinge zu tun ist einfach gut ... manchmal kann man nicht helfen , aber das Gefühl , sie sind einfach froh, dass sie keine neuen Technologien lernen müssen!
Leftaroundabout
1
@gardenhead Anscheinend werden Projekte mit einer ziemlich verrückten Geschwindigkeit veröffentlicht. Die Fähigkeit, weiter zu lernen, ist notwendig, wenn Sie in der Lage sein möchten, einen tollen Job zu finden.
Wayne Werner
19

Ich denke, deine Frage kommt von einer (verständlichen) immer verbundenen Denkweise. Das heißt, 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 Umgebung gearbeitet, die weit davon entfernt war.

Ein Militärsimulationsprojekt, an dem mein Team vor einigen Jahren gearbeitet hat. Der gesamte Code (wir sprechen von einer Codebasis von> 1 Mrd. USD) musste (laut Gesetz / internationaler Vereinbarung, Männer in dunklen Anzügen, wenn Sie dies nicht tun) auf Computern installiert sein, die physisch von jeder Internetverbindung isoliert sind . 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 Überprüfen von E-Mails und dergleichen. Und im Team dieser Maschinen gab es ein lokales Netzwerk, das offensichtlich in keiner Weise mit dem Internet verbunden war.

Die "zentrale Quelle der Wahrheit" war eine Maschine auf einem Militärstützpunkt in einem unterirdischen fensterlosen Raum, der nur aus Aschenblöcken bestand (verstärktes Gebäude, Yada-Yada). Diese Maschine auch hatte keine Internetverbindung.

In regelmäßigen Abständen würde jemand die Aufgabe haben, eine (physische) Fahrt 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 (God Tier) "zentrale" zentrale Repo zurückgeht. Ich kenne mindestens 1 anderen Auftragnehmer, der das gleiche Festplatten-Repo-Programm auch mit seinem Code durchgeführt hat.

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

Die Trennung von Git bedeutet, dass es in Umgebungen verwendet werden kann, in denen Tools zur Quellcodeverwaltung für verbundene Modelle (z. B. SVN) nicht oder nicht so einfach verwendet werden können.

Tersosauros
quelle
3
Ich bin Mitglied im Mile High (Software) Club. Ich habe Code in einer Entfernung von 35.000 Fuß festgelegt. Sicher, Flugzeuge haben jetzt Wifi , aber das war nicht immer der Fall. Und es ist schön zu wissen, dass zumindest bei einem Absturz die Möglichkeit besteht, dass mein Team meinen Code intakt erhält.
Wayne Werner
@WayneWerner das stimmt. Ich hatte darüber nachgedacht, allgemeinere Situationen zu schaffen, in denen es nicht möglich war, (fast-) immer verbunden zu sein. ZB in einem Flugzeug, Boot auf See, Raumstation, entlegenen Orten in Afrika usw.
Tersosauros
18

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

Bryan Oakley
quelle
14

Der verteilte Aspekt eines DVCS zeigt sich ständig in der Open-Source-Entwicklung in Form von Forking. Einige der Projekte, an denen ich mitarbeite, wurden vom ursprünglichen Autor aufgegeben und verfügen nun über eine Reihe von Abschnitten, bei denen die Betreuer manchmal bestimmte Funktionen voneinander abziehen. Sogar im Allgemeinen erhalten OSS-Projekte externe Beiträge über Pull-Requests, anstatt zufälligen Personen Push-Zugriff auf das Ground-Truth-Repo zu gewähren.

Dies ist kein alltäglicher Anwendungsfall, wenn ein konkretes Produkt mit einer bestimmten offiziellen Version erstellt wird. In der F / OSS-Welt ist dies jedoch die Norm und nicht die Ausnahme.

flauschige
quelle
4
Das ist auch aus historischer Sicht die richtige Antwort. Der Linux-Kernel verfügt seit langem über mehrere Quell-Repositorys (von den Entwicklern als "Bäume" bezeichnet, z. B. "Linus-Baum" oder "Andrew-Baum"). Linux wollte etwas, das diese Art der verteilten Entwicklung unterstützt, als er git entwickelte.
sleske
@Luaan Nachdem ich eine Weile darüber nachgedacht hatte, wurde mir klar, dass du recht hast. Ich habe den Wortlaut ein wenig geändert - fängt das den Unterschied ein bisschen besser ein?
flauschige
@ flauschig Klingt gut für mich;)
Luaan
9

Warum nutzt jeder Git zentral?

Wir haben uns nie getroffen, wie kommt es, dass Sie alle sagen? ;)

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

Sicher, dass viele Leute es zentral nutzen, wie CVS oder SVN. Vergessen Sie jedoch nicht die andere Funktion, die mit einem verteilten VCS einhergeht: 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.

Meiner Meinung nach ist dies ein weiteres Feature, das man nicht vergessen sollte.

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

So kann ich meine Änderungen festschreiben, eventuell laufende Squash-Commits zusammenfassen und meine Arbeit dann auf den Hauptentwicklungszweig übertragen.

Weitere Funktionen, die bei Git standardmäßig zur Verfügung stehen:

  • kryptografisch signieren Commits
  • Neuanordnen (Neuanordnen und Squash-Commits; Commits bearbeiten, nicht nur die Nachricht)
  • Rosinenpickerei
  • die Geschichte halbieren
  • Lokale Filialen und Änderungen der Lagerbestände (in Wikipedia als "Regale" bezeichnet)

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

Vielleicht ist die dezentrale Art nicht das einzige Merkmal, das die Leute dazu bringt, es zu benutzen.

  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 Mitwirkender klont, schreibt fest und sendet dann eine Pull-Anfrage.

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

  1. Ist das verteilte Arbeiten auch für die moderne Versionskontrolle wichtig, ...

Wie immer: es kommt auf die Anforderungen an.

Verwenden Sie ein dezentrales VCS, wenn ein Punkt zutrifft:

  • den Verlauf offline festschreiben oder navigieren möchten (dh das Submodul in der Berghütte in den Ferien fertigstellen)
  • Bereitstellung zentraler Repos, aber Sie möchten das "wahre" Repository auseinanderhalten, um Änderungen zu überprüfen (z. B. für große Projekte oder verteilte Teams).
  • möchten gelegentlich die gesamte Historie und die Filialen zur Verfügung stellen (eine Kopie davon) und gleichzeitig den direkten Zugriff auf das zentrale Repo verhindern (ähnlich dem zweiten Repo)
  • Sie möchten etwas git init .versionieren, ohne dies aus der Ferne speichern oder ein dediziertes Repository einrichten zu müssen (insbesondere bei Git wäre dies nur ausreichend, um bereit zu sein, etwas zu versionieren).

Es gibt noch ein paar mehr, aber vier sollten ausreichen.

... oder klingt es nur schön?

Natürlich hört es sich gut an - für Anfänger.

Versuch-Fang-endlich
quelle
Hat SVN nicht svn initirgendwann zugelegt?
immibis
5

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

Infolgedessen besteht die kluge Entscheidung darin, bei der Implementierung von Git einen Teil dieser theoretischen Flexibilität zu entfernen. In der Theorie können Repositories beliebige Graphen bilden, in der Praxis ist die übliche Wahl ein Baum. Die Vorteile der Graphentheorie werden deutlich: In einem Baum von Repositorys teilen zwei beliebige Repositorys genau einen Vorfahren. In einer zufälligen Grafik existiert die Idee eines Vorfahren nicht einmal!

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

MSalters
quelle
1
Ich bin damit einverstanden, dass die Flexibilität von Git für die meisten Anwendungsfälle verringert werden muss. Bei meinem letzten Job hatten wir keine Richtlinien für die Verwendung von Git, und es gab aufgrund dessen ständige Konflikte und Brüche. In meiner neuen Firma verwenden wir das Git Flow-Modell, wodurch die Entwicklung wesentlich rationaler und stressfreier wird.
Gardenhead
1
Es ist keine "theoretische Flexibilität", Nichtbäume zuzulassen. Beschränken Sie sich auf "nur Bäume", und Sie werden niemals in der Lage sein, Ihre Änderungen zusammenzuführen, wodurch Ihr gesamtes VCS etwas sinnlos wird.
Wildcard
2
@Wildcard: Das Zusammenführen ist mit Bäumen überhaupt kein Problem, warum sollte das so sein? Sie können natürlich nicht zwischen zufälligen Knoten zusammenführen, sondern nur zwischen Eltern / Kindern.
MSalters
1
Ich war offensichtlich nicht klar genug. Ich bezog mich auf einen Commit-Baum, nicht auf einen Dateisystembaum. Per Definition hat ein Merge-Commit mehr als ein übergeordnetes Element, und Ihr Verlaufsdiagramm ist daher kein Baum mehr, sondern eine DAG.
Wildcard
2
@Wildcard: MSalters sagte, dass Repositorys normalerweise als Bäume verbunden sind, nicht als Commits. Er sagt, dass Repos normalerweise nur eine "Upstream" -Remote haben, an die sie pushen (oder Pull-Requests ausgeben). Ich habe keine Statistiken darüber, ob das stimmt oder nicht, aber es ist eine völlig andere Behauptung als alles, was damit zu tun hat, wie viele Eltern ein Merge-Commit hat.
Steve Jessop
4

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 DVCS-fähig sind, muss Ihr primärer Arbeitsablauf nicht DVCS sein. Wenn ich git bei der Arbeit verwende, verwenden wir es zentral, mit Ausnahme der merkwürdigen Fälle, in denen das verteilte Bit für den reibungslosen Ablauf der Dinge unerlässlich war.

Die verteilte Seite der Dinge ist kompliziert. Normalerweise möchten Sie die Dinge glatt und einfach halten. Indem Sie git verwenden, stellen Sie jedoch sicher, dass Sie Zugriff auf die verteilte Seite haben, um mit den schwierigen Situationen fertig zu werden, die später auftreten können.

Cort Ammon
quelle
3

Damit ein Kollege aus einem Git-Repo auf meinem Computer zugreifen kann, muss ein Git-Daemon auf Stammebene als Hintergrundaufgabe ausgeführt werden. Ich bin sehr misstrauisch gegenüber Daemons, die auf meinem eigenen Computer oder auf meinem von der Firma bereitgestellten Laptop ausgeführt werden. Die einfachste Lösung ist "NEIN"! Damit ein Mitarbeiter aus einem Git-Repo auf meinem Computer zugreifen 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 VPN zur Unternehmens-Site und das Verschieben einer Filiale zum zentralen Repository weniger als eine Minute. Ich muss nicht einmal VPN einschalten, wenn ich im Büro bin. Meine Kollegen können leicht aus diesem Zweig ziehen.

In der dritten Hand ist mein lokales Git-Repository ein voll ausgestattetes Repository. Ich kann neue Arbeiten verrichten, einen neuen Zweig für experimentelle Arbeiten anlegen und die Arbeit wieder aufnehmen, wenn ich durcheinander bin, 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.

David Hammen
quelle
"Ich bin sehr misstrauisch gegenüber Daemons, die auf meinem eigenen Computer oder meinem von der Firma bereitgestellten Laptop ausgeführt werden." - weil das Ausführen eines Dienstes auf meinem Laptop, abgesehen von allem anderen, bedeutet, dass der Dienst nicht verfügbar ist, wenn ich den Deckel schließe! DynDNS kann bei mehreren Standorten hilfreich sein (bis zu einem gewissen Grad können Sie immer noch hinter einem NAT gefangen sein), aber es hilft nicht beim Ausschalten Ihrer Netzwerkkarte ...
Steve Jessop
Es gibt viele Möglichkeiten, ein Git-Repo sichtbar zu machen, ohne einen speziellen Daemon auszuführen. es kann über so ziemlich jede Dateifreigabe (smb, sshfs usw.) zugegriffen werden und kann sogar als einfacher alter HTTP-Speicher zur Verfügung gestellt werden.
flauschiger
2

Komplexität:

Bei einem zentralen Repository ist dies möglicherweise ein typischer Arbeitsablauf

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 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 verschiedene Möglichkeiten, um eine eventuelle Konsistenz zu erreichen. Bis dahin kann jedoch jede Menge Entwicklerzeit verschwendet werden.

Theodore Norvell
quelle
Wenn Sie abstimmen wollen, können Sie bitte einen Kommentar hinterlassen, warum?
Theodore Norvell
Nicht, dass mir die Abstimmungen etwas ausmachen. Ich möchte nur wissen, ob die Antwort irgendwie falsch ist.
Theodore Norvell
1

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 der technischen Wahrheit. Welches Werkzeugunternehmen auch immer verwendet, es muss diese Befehlskette widerspiegeln. Eine Kompanie ist wie eine Armee - man darf nicht zulassen, dass Privatpersonen einen General überstimmen.

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

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

Agent_L
quelle
-2

Vielleicht liegt es daran, dass die Lohn- und Gehaltsabrechnung zentralisiert ist, sodass wir eine zentrale Person bei Laune halten müssen, wenn wir bezahlt werden möchten.

Vielleicht liegt es daran, dass wir ein einziges Produkt entwickeln. Daher benötigen wir eine Masterkopie der Software für die Kunden.

Vielleicht liegt es daran, dass es für einen Programmierer viel einfacher ist, an einen Ort zu gehen, um alle Änderungen abzurufen, als sich mit vielen verschiedenen Computern verbinden zu müssen.

Vielleicht liegt es daran, dass die Bugdatenbank zentralisiert ist und mit dem Code synchron gehalten werden muss .

Zentralisiert zu sein ist großartig, bis es ein Problem gibt ...

Da Git ein verteiltes System ist, kann aus jedem aktuellen Repository kostengünstig ein neues Center erstellt werden (stellen Sie das Repository einfach dem Netzwerk zur Verfügung). Mit Git kann auch eine veraltete Sicherung aus den Repositorys auf den Entwicklermaschinen aktualisiert werden, um die Wiederherstellung des Centers zu vereinfachen.

Das Zusammenführen usw. auf einer lokalen Kopie eines Repositorys bei ausgefallenem Netzwerk ist sehr gut, erfordert jedoch kein verteiltes System. Es wird lediglich ein System benötigt, das eine lokale Kopie aller Daten aufbewahrt. Ebenso beim Einchecken von Code beim Fliegen etc.

Am Ende des Tages gibt es wenig Kosten für die Verteilung und einige Vorteile. Der größte Teil der Vertriebskosten entfällt auf den Bereich, der benötigt wird, wenn Sie Filialen usw. nachverfolgen möchten. Wenn Sie ein System für die Verwendung in den meisten Unternehmen entwerfen, würden Sie es nicht für den Vertrieb als zentralisierte Steuerung des Quellcodes konzipieren ist eindeutig der primäre "Anwendungsfall".

Ian
quelle