Grundlegendes zur verteilten Quellcodeverwaltung

Abgeschlossen

Strengths are cross platform, open source, offline support, and history. Best used for small codebases, evolving open course, distributed teams, and Greenfield projects.

Im Lauf der Zeit haben sich sogenannte „verteilte“ Quellcodeverwaltungs- oder Versionskontrollsysteme (kurz DVCS) zu den wichtigsten Systemen entwickelt.

Die drei beliebtesten sind Git, Mercurial und Bazaar. Diese Systeme benötigen nicht unbedingt einen zentralen Server, um alle Versionen der Projektdateien zu speichern. Stattdessen „klonen“ alle Entwickler eine Repositorykopie und verfügen damit über den vollständigen Verlauf des Projekts in ihrem lokalen Speicher. Diese Kopie (oder dieser „Klon“) enthält alle ursprünglichen Metadaten.

Diese Methode mag verschwenderisch klingen, aber in der Praxis ist sie kein Problem. Die meisten Programmierprojekte bestehen hauptsächlich aus Nur-Text-Dateien (möglicherweise aus einigen Bildern).

Und Speicherplatz ist so kostengünstig, dass das Speichern vieler Kopien einer Datei keine merklichen Auswirkungen auf den freien Speicherplatz eines lokalen Speichers hat. Moderne Systeme komprimieren die Dateien auch, um noch weniger Platz zu verwenden. So werden z. B. Objekte (und Deltas) komprimiert gespeichert, und Textdateien, die in der Programmierung verwendet werden, lassen sich gut komprimieren (etwa 60 % der ursprünglichen Größe oder 40 % Größenreduzierung durch Komprimierung).

Das Abrufen neuer Änderungen aus einem Repository wird als „Pullen“ bezeichnet. Das Verschieben Ihrer Änderungen in ein Repository wird als „Pushen“ bezeichnet. Sie verschieben Changesets (Änderungen an Dateigruppen als zusammenhängendes Ganzes), nicht Unterschiede von Einzeldateien.

Ein häufiges Missverständnis bei verteilten Versionskontrollsystemen ist, dass es kein zentrales Projektrepository geben kann. Das stimmt nicht. Nichts hindert Sie daran, eine bestimmte Kopie des Projekts als „autoritative Kopie“ festzulegen.

Dies bedeutet also, dass ein zentrales Repository für Ihre Tools damit nicht mehr erforderlich, sondern optional ist.

Vorteile gegenüber der zentralisierten Quellcodeverwaltung

Das Klonen eines gesamten Repositorys in verteilten Quellcodeverwaltungstools bietet gegenüber zentralisierten Systemen mehrere Vorteile:

  • Andere Aktionen als das Pushen und Pullen von Changesets sind schneller, da das Tool nur auf den lokalen Speicher und nicht auf einen Remoteserver zugreifen muss.
  • Das Committen neuer Changesets kann lokal erfolgen, ohne dass sie von anderen Personen gesehen werden. Wenn Sie mehrere Changesets fertiggestellt haben, können Sie alle auf einmal pushen.
  • Alle Vorgänge außer Pushen und Pullen können ohne Internetverbindung durchgeführt werden. Sie können also im Flugzeug arbeiten und sind nicht gezwungen, mehrere Fehlerbehebungen als ein großes Changeset zu committen.
  • Da alle Programmierer über eine vollständige Kopie des Projektrepositorys verfügen, können sie Änderungen zunächst mit einer oder zwei anderen Personen teilen, um Feedback zu erhalten, bevor sie die Änderungen allen zeigen.

Nachteile gegenüber der zentralisierten Quellcodeverwaltung

Es gibt fast keine Nachteile bei der Verwendung eines verteilten Quellcodeverwaltungssystems gegenüber einem zentralisierten System.

Verteilte Systeme verhindern nicht, dass Sie ein „zentrales“ Repository nutzen. Sie bieten aber noch weitere Möglichkeiten.

Die Verwendung eines verteilten Systems hat nur zwei wesentliche Nachteile:

  • Wenn Ihr Projekt viele große Binärdateien enthält, die nicht effizient komprimiert werden können, kann zum Speichern aller Versionen dieser Dateien schnell sehr viel Speicherplatz notwendig werden.
  • Wenn Ihr Projekt über einen langen Verlauf (50.000 oder mehr Changesets) verfügt, kann das Herunterladen des gesamten Verlaufs übermäßig viel Zeit und Speicherplatz in Anspruch nehmen.