Verteilte Versionskontrolle

Im Software-Entwicklung, Verteilte Versionskontrolle (auch bekannt als Distributed Revision Control) ist eine Form von Versionskontrolle in dem die vollständige Codebasis, einschließlich seiner vollen Geschichte, spiegelt sich auf dem Computer jedes Entwicklers wider.[1] Im Vergleich zur zentralisierten Versionskontrolle ermöglicht dies die automatische Verwaltung Verzweigung und Verschmelzung, beschleunigt die meisten Vorgänge (außer Druck und Ziehen), verbessert die Fähigkeit, offline zu arbeiten, und stützt sich nicht auf einen einzelnen Ort für Backups.[1][2][3] Git, das beliebteste Versionskontrollsystem der Welt,[4] ist ein verteiltes Versionskontrollsystem.

Im Jahr 2010, Softwareentwicklungsautor Joel Spolsky beschrieben verteilte Versionskontrollsysteme als "möglicherweise der größte Fortschritt in der Softwareentwicklungstechnologie in den Zehn Jahren".[2]

Verteilt gegen zentralisiert

Distributed Version Control Systems (DVCs) verwenden a Peer-To-Peer Ansatz zur Versionskontrolle im Gegensatz zu der Kundenserver Ansatz zentraler Systeme. Distributed Revision Control synchronisiert Repositories durch Übertragung Patches vom Peer zu Peer. Es gibt keine einzige zentrale Version der Codebasis; Stattdessen hat jeder Benutzer eine Arbeitskopie und den vollständigen Änderungsverlauf.

Zu den Vorteilen von DVCs (im Vergleich zu zentralisierten Systemen) gehören:

  • Ermöglicht Benutzern, produktiv zu arbeiten, wenn sie nicht mit einem Netzwerk verbunden sind.
  • Gemeinsame Operationen (wie Commits, Ansichtsgeschichte und Rückkehränderungen) sind für DVCs schneller, da nicht mit einem zentralen Server kommuniziert werden muss.[5] Bei DVCs ist Kommunikation nur erforderlich, wenn Änderungen unter anderen Kollegen geteilt werden.
  • Ermöglicht private Arbeiten, sodass Benutzer ihre Änderungen auch für frühe Entwürfe nutzen können, die sie nicht veröffentlichen möchten.
  • Das Arbeiten kopiert effektiv als Remote -Backups, wodurch es vermieden wird, auf eine physische Maschine als einzelne Ausfallspitze zu stützen.[5]
  • Ermöglicht verschiedene Entwicklungsmodelle, beispielsweise die Verwendung Entwicklungszweige oder ein Befehlshaber/Leutnantmodell.
  • Ermöglicht eine zentralisierte Kontrolle der "Release -Version" des Projekts
  • An Foss Softwareprojekte Es ist viel einfacher, a zu erstellen Projektgabel Aus einem Projekt, das aufgrund von Führungskonflikten oder Design -Meinungsverschiedenheiten ins Stocken gerät.

Zu den Nachteilen von DVCs (im Vergleich zu zentralisierten Systemen) gehören:

  • Die erste Kasse eines Repositorys ist im Vergleich zur Kasse in einem zentralisierten Versionskontrollsystem langsamer, da alle Zweige und Revisionsverlauf standardmäßig in die lokale Maschine kopiert werden.
  • Das Fehlen von Sperrmechanismen, die Teil der meisten zentralen VCs sind und immer noch eine wichtige Rolle für nicht verabscheubare Binärdateien wie grafische Assets oder zu komplexe Binär- oder XML Datenwerkzeuge BI -Pakete usw.).
  • Zusätzlicher Speicher erforderlich, damit jeder Benutzer eine vollständige Kopie des vollständigen Codebasis -Verlaufs hat.[6]
  • Erhöhte Exposition der Codebasis, da jeder Teilnehmer eine lokal verletzliche Kopie hat.

Einige ursprünglich zentralisierte Systeme bieten jetzt einige verteilte Funktionen. Zum Beispiel, Subversion ist in der Lage, viele Vorgänge ohne Netzwerk auszuführen.[7] Team Foundation Server und Visual Studio Team Services hosten jetzt zentralisierte und verteilte Versionskontroll -Repositories über Hosting Git.

In ähnlicher Weise bieten einige verteilte Systeme jetzt Funktionen an, die die Probleme der Kassenzeiten und Speicherkosten mildern, wie die Virtuelles Dateisystem für Git entwickelt von Microsoft, um mit sehr großen Codebasen zu arbeiten,[8] Dies zeigt ein virtuelles Dateisystem, das Dateien nur dann auf den lokalen Speicher herunterladen, wenn sie benötigt werden.

Arbeitsmodell

Das verteilte Modell eignet sich im Allgemeinen besser für große Projekte mit teilweise unabhängigen Entwicklern wie dem Linux -Kernel -Projekt, da Entwickler unabhängig arbeiten und ihre Änderungen für die Zusammenführung (oder Ablehnung) einreichen können. Das verteilte Modell ermöglicht flexibel die Einführung benutzerdefinierter Quellcode -Beitrags -Workflows. Das Integrator Workflow ist die am häufigsten verwendete. Im zentralisierten Modell müssen Entwickler ihre Arbeit serialisieren, um Probleme mit verschiedenen Versionen zu vermeiden.

Zentral- und Zweig -Repositories

Jedes Projekt verfügt über ein zentrales Repository, das als offizielles Repository angesehen wird, das von den Projektbeteiligern verwaltet wird. Entwickler klonen dieses Repository, um identische lokale Kopien der Codebasis zu erstellen. Quellcodeänderungen im zentralen Repository werden regelmäßig mit dem lokalen Repository synchronisiert.

Der Entwickler erstellt eine neue Filiale in seinem lokalen Repository und modifiziert den Quellcode in dieser Filiale. Sobald die Entwicklung abgeschlossen ist, muss die Änderung in das zentrale Repository integriert werden.

Anfragen ziehen

Beiträge zu einem Quellcode -Repository, das ein verteiltes Versionskontrollsystem verwendet Anfrage ziehen, auch bekannt als a Anfrage zusammenführen.[9] Der Mitwirkende beantragt den Projektbetreuer ziehens Die Quellcode Änderung, daher der Name "Pull -Anforderung". Der Betreuer muss verschmelzen Die Pull -Anfrage, wenn der Beitrag Teil der Quellbasis werden sollte.[10]

Der Entwickler schafft eine Pull -Anfrage, um die Instandnehmer über eine neue Änderung zu informieren. Mit jeder Zuganfrage wird ein Kommentar -Thread zugeordnet. Dies erlaubt Fokussierte Diskussion von Codeänderungen. Eingereichte Pull -Anfragen sind für alle mit Repository -Zugriff sichtbar. Eine Pull -Anfrage kann von den Betreuern angenommen oder abgelehnt werden.[11]

Sobald die Pull -Anfrage überprüft und genehmigt wurde, wird er in das Repository zusammengefasst. Abhängig vom festgelegten Workflow muss der Code möglicherweise getestet werden, bevor sie in die offizielle Veröffentlichung einbezogen werden. Daher enthalten einige Projekte eine spezielle Filiale zur Verschmelzung ungetesteter Zuganfragen.[10][12] Andere Projekte führen eine automatisierte Testsuite bei jeder Pull -Anfrage durch, indem Sie a verwenden kontinuierliche Integration Werkzeug wie Travis CIund der Rezensent prüft, dass jeder neue Code eine entsprechende Testabdeckung hat.

Geschichte

Die ersten Open-Source-DVCS-Systeme enthalten Bogen, Monoton, und Darcs. Open -Source -DVCSS waren jedoch bis zur Veröffentlichung von nie sehr beliebt Git und Quecksilber.

Bitkeeper wurde bei der Entwicklung der verwendet Linux Kernel von 2002 bis 2005.[13] Die Entwicklung von Git, jetzt das beliebteste Versionskontrollsystem der Welt,[4] wurde von der Entscheidung des Unternehmens veranlasst, die Bitkeeper dazu veranlasste, die freie Lizenz aufzuheben, die Linus Torvalds und einige andere Linux -Kernel -Entwickler zuvor ausgenutzt hatten.[13]

Siehe auch

Verweise

  1. ^ a b Chacon, Scott; Straub, Ben (2014). "Erste Schritte - über die Versionskontrolle". Pro Git (2. Aufl.). Apress. Kapitel 1.1. Abgerufen 4. Juni 2019.
  2. ^ a b Spolsky, Joel (17. März 2010). "Distributed Version Control ist hier, um zu bleiben, Baby". Joel über Software. Abgerufen 4. Juni 2019.
  3. ^ "Intro zu verteilter Versionskontrolle (illustriert)". www.betterexplained.com. Abgerufen 7. Januar 2018.
  4. ^ a b "Popularität der Versionskontrollsysteme im Jahr 2016". www.rhodecode.com. Abgerufen 7. Januar 2018.
  5. ^ a b O'Sullivan, Bryan. "Distributed Revision Control mit Quecksilber". Abgerufen 13. Juli, 2007.
  6. ^ "Was ist Versionskontrolle: Zentralisierte vs. DVCs". www.atlassian.com. Abgerufen 7. Januar 2018.
  7. ^ Osdir.com. "Subversion für CVS -Benutzer :: osdir.com :: Open Source, Linux News & Software". Osdir.com. Archiviert von das Original am 2016-08-23. Abgerufen 2013-07-22.
  8. ^ Jonathan Allen (2017-02-08). "Wie Microsoft das Problem von Git mit großen Repositorys gelöst hat". Abgerufen 2019-08-06.
  9. ^ Sijbrandij, Sytse (29. September 2014). "Gitlab Flow". Gitlab. Abgerufen 4. August 2018.
  10. ^ a b Johnson, Mark (8. November 2013). "Was ist eine Pull -Anfrage?". Oaawatch. Abgerufen 27. März 2016.
  11. ^ "Verwenden von Pull -Anfragen". Github. Abgerufen 27. März 2016.
  12. ^ "Eine Pull -Anfrage machen". Atlassian. Abgerufen 27. März 2016.
  13. ^ a b McAllister, Neil. "Linus Torvalds 'Bitkeeper -Fehler". InfoWorld. Abgerufen 2017-03-19.

Externe Links