Geekly articles weekly

Geschichte der Versionskontrollsysteme



In diesem Artikel vergleichen wir aus technischer Sicht die bekanntesten Versionskontrollsysteme (in Zukunft planen wir, die Liste zu erweitern):

  1. Erste Generation
  2. Zweite Generation
  3. Dritte Generation

Die Versionskontrollsysteme der ersten Generation (VCS) verfolgten Änderungen in einzelnen Dateien, und die Bearbeitung wurde nur lokal und von jeweils einem Benutzer unterstützt. Die Systeme basierten auf der Annahme, dass sich alle Benutzer auf demselben gemeinsamen Unix-Knoten bei ihren Konten anmelden.

VCS der zweiten Generation führte die Netzwerkunterstützung ein, was zu zentralisierten Repositorys mit „offiziellen“ Versionen von Projekten führte. Dies war ein bedeutender Fortschritt, da mehrere Benutzer gleichzeitig mit dem Code arbeiten und sich auf dasselbe zentrale Repository festlegen konnten. Setzt jedoch den erforderlichen Zugriff auf das Netzwerk fest.

Die dritte Generation besteht aus verteiltem VCS, bei dem alle Kopien des Repositorys als gleich gelten. Es gibt kein zentrales Repository. Dies ebnet den Weg für Festschreibungen, Verzweigungen und Zusammenführungen, die lokal ohne Zugriff auf das Netzwerk erstellt und bei Bedarf in andere Repositorys verschoben werden.

VCS Release Timeline


Im folgenden Diagramm sind die Daten aufgeführt, an denen diese Tools erschienen sind:



SCCS (Source Code Control System): erste Generation


SCCS gilt als eines der ersten erfolgreichen Versionskontrollsysteme. Es wurde 1972 von Mark Rochkind von Bell Labs entwickelt. Das System ist in C geschrieben und für die Verfolgung von Quelldateiversionen ausgelegt. Darüber hinaus wurde die Suche nach Fehlerquellen im Programm erheblich erleichtert. Die grundlegende Architektur und Syntax von SCCS ermöglicht es, die Wurzeln moderner VCS-Tools zu verstehen.

Architektur


Wie die meisten modernen Systeme verfügt SCCS über eine Reihe von Befehlen zum Arbeiten mit Dateiversionen:

  1. Eincheckdateien für die Verlaufsverfolgung in SCCS.
  2. Checken Sie bestimmte Versionen von Dateien aus, um sie zu überprüfen oder zu kompilieren.
  3. Extrahieren Sie bestimmte Versionen zum Bearbeiten.
  4. Einführung neuer Dateiversionen mit Kommentaren, die die Änderungen erläutern.
  5. Verwerfen Sie die an der extrahierten Datei vorgenommenen Änderungen.
  6. Wichtige Änderungen beim Verzweigen und Zusammenführen.
  7. Datei-Änderungsprotokoll.

Beim Hinzufügen einer Verfolgungsdatei zu SCCS wird ein besonderer Dateityp erstellt, der als s- oder . Sie wird nur mit dem Präfix s. als Quelldatei bezeichnet s. und wird im SCCS Unterverzeichnis gespeichert. Daher wird für die Datei test.txt eine Verlaufsdatei test.txt im Verzeichnis ./SCCS/ . Zum Zeitpunkt der Erstellung enthält die Verlaufsdatei den anfänglichen Inhalt der Quelldatei sowie einige Metadaten, mit deren Hilfe Versionen nachverfolgt werden können. Hier werden Prüfsummen gespeichert, um sicherzustellen, dass der Inhalt nicht geändert wurde. Der Inhalt der Verlaufsdatei wird nicht komprimiert oder codiert (wie im VCS der nächsten Generation).

Da der Inhalt der Quelldatei jetzt in der Verlaufsdatei gespeichert ist, kann er zum Anzeigen, Kompilieren oder Bearbeiten in das Arbeitsverzeichnis extrahiert werden. Sie können Änderungen an der Verlaufsdatei vornehmen, z. B. Zeilen hinzufügen, ändern und löschen, wodurch die Versionsnummer erhöht wird.

Nachfolgende Dateizugriffe speichern nur oder Änderungen und nicht den gesamten Inhalt. Dadurch wird die Größe der Verlaufsdatei verringert. Jedes Delta wird in einer Verlaufsdatei in einer Struktur gespeichert, die als - . Wie bereits erwähnt, wird der tatsächliche Inhalt einer Datei mehr oder weniger wörtlich kopiert, mit speziellen Escape-Sequenzen zum Markieren von Anfang und Ende von Abschnitten hinzugefügter und gelöschter Inhalte. Da SCCS-Verlaufsdateien keine Komprimierung verwenden, sind sie normalerweise größer als die tatsächliche Datei, in der Änderungen verfolgt werden. SCCS verwendet eine Methode namens , die eine konstante Abrufzeit unabhängig vom Alter der abgerufenen Version garantiert, dh ältere Versionen werden mit der gleichen Geschwindigkeit wie neue Versionen abgerufen.

Es ist wichtig zu beachten, dass alle Dateien separat verfolgt und aufgezeichnet werden. Es ist nicht möglich, Änderungen in mehreren Dateien als ein einzelner atomarer Block zu suchen, wie dies bei Commits in Git der Fall ist. Jede nachverfolgte Datei verfügt über eine eigene Verlaufsdatei, in der der Änderungsverlauf gespeichert wird. Im Allgemeinen bedeutet dies, dass die Versionsnummern verschiedener Dateien in einem Projekt normalerweise nicht übereinstimmen. Sie können diese Versionen jedoch vereinbaren, indem Sie alle Dateien im Projekt gleichzeitig bearbeiten (ohne sie tatsächlich zu ändern) und alle Dateien gleichzeitig hinzufügen. Dies erhöht gleichzeitig die Versionsnummer für alle Dateien und hält sie konsistent. Beachten Sie jedoch, dass dies nicht dasselbe ist wie das Einschließen mehrerer Dateien in einem einzelnen Commit, wie in Git. In SCCS wird jeder Datei ein individueller Verlauf hinzugefügt, anders als bei einem großen Commit, bei dem alle Änderungen gleichzeitig vorgenommen werden.

Wenn eine Datei zum Bearbeiten in SCCS extrahiert wird, wird sie gesperrt, sodass sie von niemand anderem bearbeitet werden kann. Dies verhindert das Überschreiben von Änderungen durch andere Benutzer, schränkt jedoch auch die Entwicklung ein, da zu einem bestimmten Zeitpunkt nur ein Benutzer mit dieser Datei arbeiten kann.

SCCS unterstützt Zweige, in denen Änderungssequenzen in einer bestimmten Datei gespeichert werden. Sie können einen Zweig mit der Originalversion oder einem anderen Zweig zusammenführen.

Hauptteams


Das Folgende ist eine Liste der am häufigsten verwendeten SCCS-Befehle.

  • sccs create <filename.ext> : sccs create <filename.ext> eine neue Datei zu SCCS hinzu und erstellt eine neue Verlaufsdatei dafür (standardmäßig im Verzeichnis ./SCCS/ ).
  • sccs get <filename.ext> : Extrahiert die Datei aus der entsprechenden Verlaufsdatei und legt sie schreibgeschützt im Arbeitsverzeichnis ab.
  • sccs edit <filename.ext> : Extrahiert die Datei zur Bearbeitung aus der entsprechenden Verlaufsdatei. Sperren Sie die Verlaufsdatei, damit andere Benutzer sie nicht ändern können.
  • sccs delta <filename.ext> : Änderungen an der angegebenen Datei hinzufügen. Das System fordert einen Kommentar an, speichert die Änderungen in der Verlaufsdatei und gibt die Sperre frei.
  • sccs prt <filename.ext> : sccs prt <filename.ext> das Änderungsprotokoll für die überwachte Datei an.
  • sccs diffs <filename.ext> : sccs diffs <filename.ext> die Unterschiede zwischen der aktuellen Arbeitskopie der Datei und dem Status der Datei beim Extrahieren an.

Weitere Informationen zu SCCS-Interna finden Sie im Eric Allman -Handbuch und im Oracle Programming Utility-Handbuch .

Beispiel für eine SCCS-Verlaufsdatei


 ^Ah20562 ^As 00001/00001/00002 ^Ad D 1.3 19/11/26 14:37:08 jack 3 2 ^Ac Here is a comment. ^Ae ^As 00002/00000/00001 ^Ad D 1.2 19/11/26 14:36:00 jack 2 1 ^Ac No. ^Ae ^As 00001/00000/00000 ^Ad D 1.1 19/11/26 14:35:27 jack 1 0 ^Ac date and time created 19/11/26 14:35:27 by jack ^Ae ^Au ^AU ^Af e 0 ^At ^AT ^AI 1 Hi there ^AE 1 ^AI 2 ^AD 3 This is a test of SCCS ^AE 2 ^AE 3 ^AI 3 A test of SCCS ^AE 3

RCS (Revision Control System): erste Generation


RCS wurde 1982 von Walter Tihey in C als Alternative zum SCCS-System geschrieben, das zu diesem Zeitpunkt noch kein Open Source-System war.

Architektur


RCS hat viel mit seinem Vorgänger gemeinsam, darunter:

  • Versionierung für jede Datei separat.
  • Änderungen an mehreren Dateien können nicht zu einem einzigen Commit zusammengefasst werden.
  • Verfolgte Dateien können nicht von mehreren Benutzern gleichzeitig bearbeitet werden.
  • Keine Netzwerkunterstützung.
  • Versionen jeder nachverfolgten Datei werden in der entsprechenden Verlaufsdatei gespeichert.
  • Verzweigen und Zusammenführen von Versionen nur für einzelne Dateien.

Wenn eine Datei zum ersten Mal zu RCS hinzugefügt wird, wird eine entsprechende Verlaufsdatei für sie im lokalen Speicher im lokalen Verzeichnis ./RCS/ . Eine Erweiterung ,v , wird zu dieser Datei hinzugefügt, d. test.txt Eine Datei mit dem Namen test.txt wird von einer Datei mit dem Namen test.txt,v .

RCS verwendet ein Reverse-Delta-Schema zum Speichern von Änderungen. Wenn Sie eine Datei hinzufügen, wird eine vollständige Momentaufnahme ihres Inhalts in der Verlaufsdatei gespeichert. Wenn die Datei geändert und erneut zurückgegeben wird, wird ein Delta basierend auf dem vorhandenen Inhalt der Verlaufsdatei berechnet. Das alte Bild wird verworfen und das neue zusammen mit dem Delta gespeichert, um zum alten Zustand zurückzukehren. Dies wird als , da RCS zum Abrufen einer älteren Version die neueste Version verwendet und nacheinander Deltas anwendet, bis die gewünschte Version erreicht ist. Mit dieser Methode können Sie die aktuellen Versionen sehr schnell abrufen, da immer ein vollständiger Schnappschuss der aktuellen Revision verfügbar ist. Je älter die Version ist, desto länger dauert die Überprüfung, da Sie immer mehr Deltas überprüfen müssen.

In SCCS ist dies anders: Das Abrufen einer beliebigen Version dauert genauso lange. Außerdem wird die Prüfsumme nicht in den RCS-Verlaufsdateien gespeichert, sodass die Dateiintegrität nicht gewährleistet werden kann.

Hauptteams


Nachfolgend finden Sie eine Liste der am häufigsten verwendeten RCS-Befehle:

  • <filename.ext> : Fügt eine neue Datei zu RCS hinzu und erstellt eine neue Verlaufsdatei dafür (standardmäßig im Verzeichnis ./RCS/ ).
  • co <filename.ext> : Extrahiert die Datei aus der entsprechenden Verlaufsdatei und legt sie schreibgeschützt im Arbeitsverzeichnis ab.
  • co -l <filename.ext> : Extrahiert die Datei zur Bearbeitung aus der entsprechenden Verlaufsdatei. Sperren Sie die Verlaufsdatei, damit andere Benutzer sie nicht ändern können.
  • ci <filename.ext> : Fügt Dateiänderungen hinzu und erstellt eine neue Revision in der entsprechenden Verlaufsdatei.
  • merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> : Änderungen von zwei modifizierten merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> derselben übergeordneten Datei.
  • rcsdiff <filename.ext> : rcsdiff <filename.ext> die Unterschiede zwischen der aktuellen Arbeitskopie der Datei und dem Status der Datei beim Extrahieren an.
  • rcsclean : Arbeitsdateien löschen, die nicht gesperrt sind.

Weitere Informationen zu internen RCS-Komponenten finden Sie im GNU RCS-Handbuch .

Beispiel einer RCS-Verlaufsdatei


 head 1.2; access; symbols; locks; strict; comment @# @; 1.2 date 2019.11.25.05.51.55; author jstopak; state Exp; branches; next 1.1; 1.1 date 2019.11.25.05.49.02; author jstopak; state Exp; branches; next ; desc @This is a test. @ 1.2 log @Edited the file. @ text @hi there, you are my bud. You are so cool! The end. @ 1.1 log @Initial revision @ text @d1 5 a5 1 hi there @

CVS (Concurrent Versions System): zweite Generation


CVS wurde 1986 von Dick Grun erstellt, um die Versionskontrolle durch Netzwerkunterstützung zu erweitern. Es ist auch in C geschrieben und markiert die Geburtsstunde der zweiten Generation von VCS-Tools, dank derer geografisch verteilte Entwicklungsteams die Möglichkeit haben, gemeinsam an Projekten zu arbeiten.

Architektur


CVS ist ein Frontend für RCS. Es enthält einen neuen Befehlssatz für die Interaktion mit Dateien in einem Projekt. Unter der Haube werden jedoch dasselbe RCS-Verlaufsdateiformat und dieselben RCS-Befehle verwendet. Mit CVS konnten erstmals mehrere Entwickler gleichzeitig mit denselben Dateien arbeiten. Dies wird mithilfe eines zentralen Repository-Modells implementiert. Der erste Schritt besteht darin, ein zentrales Repository mithilfe von CVS auf dem Remoteserver zu konfigurieren. Projekte können dann in das Repository importiert werden. Wenn ein Projekt in CVS importiert wird, wird jede Datei in eine Verlaufsdatei ,v konvertiert und in einem zentralen Verzeichnis gespeichert: . Das Repository befindet sich normalerweise auf einem Remote-Server, auf den über ein lokales Netzwerk oder das Internet zugegriffen werden kann.

Der Entwickler erhält eine Kopie des Moduls, die in das Arbeitsverzeichnis auf seinem lokalen Computer kopiert wird. Bei diesem Vorgang werden keine Dateien blockiert, sodass die Anzahl der Entwickler, die gleichzeitig mit dem Modul arbeiten können, unbegrenzt ist. Entwickler können ihre Dateien ändern und Änderungen nach Bedarf festschreiben (Festschreiben). Wenn ein Entwickler eine Änderung festschreibt, sollten andere Entwickler ihre Arbeitskopien mithilfe des (normalerweise) automatisierten Zusammenführungsprozesses aktualisieren, bevor sie ihre Änderungen festschreiben. Manchmal müssen Sie Zusammenführungskonflikte vor dem Festschreiben manuell lösen. CVS bietet auch die Möglichkeit, Zweige zu erstellen und zusammenzuführen.

Hauptteams


  • export CVSROOT=<path/to/repository> : export CVSROOT=<path/to/repository> das Stammverzeichnis des CVS-Repositorys fest, damit Sie es nicht in jedem Befehl angeben müssen.
  • cvs import -m 'Import module' <module-name> <vendor-tag> <release-tag> : Importiert Verzeichnisse mit Dateien in das CVS-Modul. Wechseln Sie in das Stammverzeichnis des Projekts, bevor Sie diesen Vorgang starten.
  • cvs checkout <module-name> : Kopieren Sie das Modul in das Arbeitsverzeichnis.
  • cvs commit <filename.ext> : cvs commit <filename.ext> die geänderte Datei zurück in das Modul im zentralen Repository.
  • cvs add <filename.txt> : cvs add <filename.txt> eine neue Datei hinzu, um Änderungen cvs add <filename.txt> .
  • cvs update : Aktualisieren Sie die Arbeitskopie, indem Sie festgeschriebene Änderungen zusammenführen, die im zentralen Repository vorhanden sind, jedoch nicht in der Arbeitskopie.
  • cvs status : cvs status allgemeine Informationen zur extrahierten Arbeitskopie des Moduls an.
  • cvs tag <tag-name> <files> : cvs tag <tag-name> <files> einer Datei oder einer Gruppe von Dateien ein Tag hinzu.
  • cvs tag -b <new-branch-name> neuen Zweigs cvs tag -b <new-branch-name> : cvs tag -b <new-branch-name> einen neuen Zweig im Repository (Sie müssen ihn vor der lokalen Arbeit extrahieren).
  • cvs checkout -r <branch-name> : Extrahiert eine vorhandene Filiale in das Arbeitsverzeichnis.
  • cvs update -j <branch-to-merge> : Führt einen vorhandenen Branch mit einer lokalen Arbeitskopie zusammen.

Weitere Informationen zu den internen Komponenten von CVS finden Sie im GNU CVS-Handbuch und in Dick Grohns Artikel .

Beispiel für eine CVS-Verlaufsdatei


 head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jack:1.1.1; locks ; strict; comment @# @; 1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches 1.1.1.1; next ; commitid zsEBhVyPc4lonoMB; 1.1.1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches ; next ; commitid zsEBhVyPc4lonoMB; desc @@ 1.1 log @Initial revision @ text @hi there @ 1.1.1.1 log @Imported sources @ text @@

SVN (Subversion): Zweite Generation


Subversion wurde im Jahr 2000 von Collabnet Inc. erstellt und wird derzeit von der Apache Software Foundation unterstützt. Das System ist in C geschrieben und als zuverlässigere zentrale Lösung als CVS konzipiert.

Architektur


Wie CVS verwendet Subversion ein zentrales Repository-Modell. Remotebenutzer benötigen eine Netzwerkverbindung, um eine Festschreibung für das zentrale Repository vorzunehmen.

Subversion führte die Funktionalität von Atomic Commits mit der Garantie ein, dass das Commit entweder vollständig erfolgreich ist oder im Falle eines Problems vollständig abgebrochen wird. In CVS kann das Repository im Falle einer Fehlfunktion während eines Commits (z. B. aufgrund eines Netzwerkfehlers) in einem beschädigten und inkonsistenten Zustand verbleiben. Darüber hinaus kann ein Commit oder eine Version in Subversion mehrere Dateien und Verzeichnisse enthalten. Dies ist wichtig, da Sie so Zusammenfassungen verwandter Änderungen als gruppierter Block und nicht wie in früheren Systemen für jede Datei einzeln nachverfolgen können.

Subversion verwendet derzeit das Dateisystem FSFS (File System atop the File System). Hier wird eine Datenbank mit der Struktur von Dateien und Verzeichnissen erstellt, die dem Host-Dateisystem entsprechen. Ein einzigartiges Merkmal von FSFS ist, dass es nicht nur Dateien und Verzeichnisse, sondern auch deren Versionen nachverfolgen kann. Dies ist ein zeitkritisches Dateisystem. Verzeichnisse sind in Subversion auch vollständige Objekte. Sie können leere Verzeichnisse an das System übergeben, während der Rest (auch Git) sie nicht bemerkt.

Wenn Sie ein Subversion-Repository erstellen, wird eine (fast) leere Datenbank mit Dateien und Ordnern in ihrer Zusammensetzung erstellt. Das Verzeichnis db/revs wird erstellt, in dem alle Versionsverfolgungsinformationen für die hinzugefügten (festgeschriebenen) Dateien gespeichert werden. Jedes Commit (das Änderungen in mehreren Dateien enthalten kann) wird in einer neuen Datei im revs Verzeichnis gespeichert und erhält einen Namen mit einer fortlaufenden numerischen Kennung, die mit 1 beginnt. Das erste Commit speichert den gesamten Inhalt der Datei. Zukünftige Commits derselben Datei speichern nur Änderungen, die auch als oder Deltas bezeichnet werden, um Speicherplatz zu sparen. Darüber hinaus werden Deltas mit lz4 oder zlib Komprimierungsalgorithmen komprimiert, um die Größe zu verringern.

Ein solches System funktioniert nur bis zu einem bestimmten Punkt. Deltas sparen zwar Platz, aber wenn es viele gibt, ist viel Zeit für den Vorgang erforderlich, da alle Deltas verarbeitet werden müssen, um den aktuellen Status der Datei wiederherzustellen. Aus diesem Grund speichert Subversion standardmäßig bis zu 1023 Deltas pro Datei und erstellt dann eine neue vollständige Kopie der Datei. Dies sorgt für ein ausgewogenes Verhältnis von Speicher und Geschwindigkeit.

SVN verwendet nicht das übliche Verzweigungs- und Kennzeichnungssystem. Die reguläre Subversion-Repository-Vorlage enthält drei Ordner im Stammverzeichnis:

  • trunk/
  • branches/
  • tags/

Der trunk/ Verzeichnis wird für die Produktionsversion des Projekts verwendet. Das Verzeichnis " branches/ - zum Speichern von Unterordnern, die einzelnen Zweigen entsprechen. Das Verzeichnis tags/ dient zum Speichern von Tags, die bestimmte (normalerweise wichtige) Versionen eines Projekts darstellen.

Hauptteams


  • svn create <path-to-repository> : Erstellt eine neue leere Repository-Shell im angegebenen Verzeichnis.
  • svn import <path-to-project> <svn-url> : Importiert das Dateiverzeichnis in das angegebene Subversion-Repository.
  • svn checkout <svn-path> <path-to-checkout> : Kopieren Sie das Repository in das Arbeitsverzeichnis.
  • svn commit -m 'Commit message' : Festschreiben einer Reihe geänderter Dateien und Ordner zusammen mit der Nachricht.
  • svn add <filename.txt> : Fügt eine neue Datei hinzu, um Änderungen nachzuverfolgen.
  • svn update : Aktualisieren Sie die Arbeitskopie, indem Sie festgeschriebene Änderungen zusammenführen, die im zentralen Repository vorhanden sind, jedoch nicht in der Arbeitskopie.
  • svn status : Zeigt eine Liste der überwachten Dateien an, die sich im Arbeitsverzeichnis geändert haben (falls vorhanden).
  • svn info : allgemeine Informationen zur extrahierten Kopie.
  • svn copy <branch-to-copy> <new-branch-path-and-name> : Erstellt einen neuen Zweig, indem ein vorhandener kopiert wird.
  • svn switch <existing-branch> : Wechselt das Arbeitsverzeichnis zu einem existierenden Zweig. Dies ermöglicht es Ihnen, Dateien von dort zu nehmen.
  • svn merge <existing-branch> : Führt den angegebenen Zweig mit dem aktuellen Zweig zusammen, der in das Arbeitsverzeichnis kopiert wurde. Bitte beachten Sie, dass Sie später ein Commit durchführen müssen.
  • svn log : svn log den Verlauf der Festschreibungen und die entsprechenden Meldungen für den aktiven Zweig an.

Weitere Informationen zu den internen Komponenten von SVN finden Sie unter Subversion-Versionierung .

Beispiel einer SVN-Verlaufsdatei


 DELTA SVN^B^@^@ ^B ^A<89> hi there ENDREP id: 2-1.0.r1/4 type: file count: 0 text: 1 3 21 9 12f6bb1941df66b8f138a446d4e8670c 279d9035886d4c0427549863c4c2101e4a63e041 0-0/_4 cpath: /trunk/hi.txt copyroot: 0 / DELTA SVN^B^@^@$^B%^A¤$K 6 hi.txt V 15 file 2-1.0.r1/4 END ENDREP id: 0-1.0.r1/6 type: dir count: 0 text: 1 5 48 36 d84cb1c29105ee7739f3e834178e6345 - - cpath: /trunk copyroot: 0 / DELTA SVN^B^@^@'^B#^A¢'K 5 trunk V 14 dir 0-1.0.r1/6 END ENDREP id: 0.0.r1/2 type: dir pred: 0.0.r0/2 count: 1 text: 1 7 46 34 1d30e888ec9e633100992b752c2ff4c2 - - cpath: / copyroot: 0 / _0.0.t0-0 add-dir false false false /trunk _2.0.t0-0 add-file true false false /trunk/hi.txt L2P-INDEX ^A<80>@^A^A^A^M^H^@ä^H÷^Aé^FDÎ^Bzè^AP2L-INDEX ^A<91>^E<80><80>@^A?^@'2^@<8d>»Ý<90>^C§^A^X^@õ ½½^N= ^@ü<8d>Ôã^Ft^V^@<92><9a><89>Ã^E; ^@<8a>åw|I^@<88><83>Î<93>^L`^M^@ù<92>À^Eïú?^[^@^@657 6aad60ec758d121d5181ea4b81a9f5f4 688 75f59082c8b5ab687ae87708432ca406I

Git: dritte Generation


Das Git-System wurde 2005 von Linus Torvalds (Erfinder von Linux) entwickelt. Es ist hauptsächlich in C in Kombination mit einigen Befehlszeilenskripten geschrieben. Unterscheidet sich von VCS in Funktionen, Flexibilität und Geschwindigkeit. Torvalds hat das System ursprünglich für die Linux-Codebasis geschrieben, aber mit der Zeit hat sich sein Anwendungsbereich erweitert, und heute ist es das beliebteste Versionskontrollsystem der Welt.

Architektur


Git ist ein verteiltes System. Es gibt kein zentrales Repository: Alle Kopien werden gleich erstellt, was sich stark vom VCS der zweiten Generation unterscheidet, bei dem die Arbeit auf dem Hinzufügen und Extrahieren von Dateien aus dem zentralen Repository basiert. Dies bedeutet, dass Entwickler Änderungen sofort miteinander austauschen können, bevor sie ihre Änderungen in einer offiziellen Zweigstelle zusammenführen.

Darüber hinaus können Entwickler ihre Änderungen an der lokalen Kopie des Repositorys vornehmen, ohne andere Repositorys zu kennen. Dies ermöglicht Commits, ohne mit einem Netzwerk oder dem Internet verbunden zu sein. Entwickler können lokal offline arbeiten, bis sie bereit sind, ihre Arbeit mit anderen zu teilen. Zu diesem Zeitpunkt werden die Änderungen zur Überprüfung, zum Testen oder zur Bereitstellung an andere Repositorys gesendet.

Wenn eine Datei zum Verfolgen in Git hinzugefügt wird, wird sie mit dem zlib Komprimierungsalgorithmus komprimiert. Das Ergebnis wird mit der SHA-1-Hash-Funktion gehasht. Dies ergibt einen eindeutigen Hash, der speziell mit dem Inhalt dieser Datei übereinstimmt. Git speichert es in der , die sich in einem versteckten Ordner .git/objects . Der Dateiname ist der generierte Hash und die Datei enthält komprimierten Inhalt. Diese Dateien werden als und jedes Mal erstellt, wenn eine neue Datei (oder eine geänderte Version einer vorhandenen Datei) zum Repository hinzugefügt wird.

Git implementiert einen Staging-Index, der als Zwischenbereich für Änderungen dient, die für das Festschreiben vorbereitet werden. Bei der Vorbereitung neuer Änderungen wird auf deren komprimierten Inhalt in einer speziellen Indexdatei verwiesen, die die Form eines Baumobjekts hat. Ein Baum ist ein Git-Objekt, das Blobs mit ihren tatsächlichen Dateinamen, Dateiberechtigungen und Verknüpfungen zu anderen Bäumen verknüpft und somit den Status einer bestimmten Gruppe von Dateien und Verzeichnissen darstellt. , , Git. , , , . (-), .

, Git — , — , . (loose objects). , Git , . , , Git . , . .pack , .idx ( ) .

, . .


  • git init : Git ( .git ).
  • git clone <git-url> : Git URL.
  • git add <filename.ext> : ( ).
  • git commit -m 'Commit message' : .
  • git status : , , , . .
  • git branch <new-branch> : .
  • git checkout <branch> : .
  • git merge <branch> : , .
  • git pull : , , , .
  • git push : .
  • git log : .
  • git stash : , .

, Git, Git . . Pro Git .

, Git


37d4e6c5c48ba0d245164c4e10d5f41140cab980 :

 hi there

b769f35b07fbe0076dcfc36fd80c121d747ccc04 :

 100644 blob 37d4e6c5c48ba0d245164c4e10d5f41140cab980hi.txt

dc512627287a61f6111705151f4e53f204fbda9b :

 tree b769f35b07fbe0076dcfc36fd80c121d747ccc04 author Jacob Stopak 1574915303 -0800 committer Jacob Stopak 1574915303 -0800 Initial commit

Mercurial:


Mercurial 2005 Python. Linux, Git. , .

Architektur


Mercurial — , . Mercurial , Git, SHA-1, .

Mercurial, revlog .hg/store/data/ . revlog ( ) VCS, CVS, RCS SCCS. Git, , Mercurial revlog . . , . .

revlog , , .i .d . .d . .i .d . .i . revlog . - nodeid .

Mercurial . revlog — , . , revlog, nodeids, , . . - nodeid .

, Mercurial revlog, changelog, . , :

  • nodeid : , .
  • nodeid : Mercurial . ( ) ID.



changelog , nodeid .


  • hg init : Mercurial ( .hg ).
  • hg clone <hg-url> : Mercurial URL.
  • hg add <filename.ext> : .
  • hg commit -m 'Commit message' : .
  • hg status : , , , ..
  • hg update <revision> : .
  • hg merge <branch> : , .
  • hg pull : , .
  • hg push : .
  • hg log : .

Mercurial


:

 hey.txt208b6e0998e8099b16ad0e43f036ec745d58ec04 hi.txt74568dc1a5b9047c8041edd99dd6f566e78d3a42

(changelog):

 b8ee947ce6f25b84c22fbefecab99ea918fc0969 Jacob Stopak 1575082451 28800 hey.txt Add hey.txt

Mercurial:

Source: https://habr.com/ru/post/de478752/

More articles:


All Articles