Versionskontrolle: Warum Sie ohne sie nicht leben können

Wenn Sie einen Computer verwenden, sind Sie wahrscheinlich mit dem Problem unterschiedlicher Dateiversionen konfrontiert. Unabhängig davon, ob es sich um Textdateien, Datendateien oder Programmcode handelt, den Sie geschrieben haben, stehen Sie immer vor der Entscheidung, ob Sie die vorherige Version speichern und ersetzen oder zusätzlich zur vorherigen Version speichern möchten.

Für einzelne Entwickler ist es bereits eine Herausforderung, die verschiedenen Versionen eines Programms im Auge zu behalten, ganz zu schweigen von den verschiedenen Backups, die Sie möglicherweise erstellen.

Stellen Sie sich nun vor, Sie arbeiten als Teil eines Teams an einem Projekt, das Text, Multimedia und Codierung umfasst – kurz gesagt, eine Vielzahl von Informationen in Arbeit.

Stellen Sie sich weiter vor: Angenommen, jede Daten- oder Programmdatei wird von mehreren Personen bearbeitet („Parallelität“) – jede Person fügt hinzu, speichert, bearbeitet und speichert erneut. Wie um alles in der Welt werden Sie wissen, wer was wann und warum getan hat und in der Lage sein, all diese Veränderungen zu verfolgen??

Sie benötigen eine Versionskontrolle (VC).

In diesem Artikel werden wir uns ansehen, was Versionskontrolle ist und wie sie sich im Laufe der Jahre bis zur neuesten Generation entwickelt hat.

Insbesondere werden wir uns Git ansehen, die immer beliebter werdende Versionskontrollanwendung von Leuten, die Linux entwickelt haben, und einige Beispiele sehen, wie Sie Git verwenden würden, um die Kontrolle über all diese verschiedenen Revisionen Ihrer Dateien zurückzugewinnen.

Eine Grundierung für VC Jargon

Die Versionskontrolle hat eine eigene Sprache. Nachdem angegeben wurde, welche Verzeichnisse oder Gruppen von Dateien nachverfolgt werden sollen, werden die Verzeichnisse oder Dateien als Repository oder Repo bezeichnet.

Änderungen werden automatisch nachverfolgt, jedoch nur als einzelne Sammlung von Aktionen, die als Commit bezeichnet werden, und als Änderungssatz mit einer eindeutigen Versionsnummer aufgezeichnet. Dadurch wird sichergestellt, dass Sie die neueste Version einer Datei aufrufen können.

Wenn Sie zwei Revisionen vergleichen möchten (z. B. wenn sich irgendwann ein Fehler in Ihren Code eingeschlichen hat), sollten Sie mit dem Versionskontroll-Tool zwei Dateien unterscheiden können, um die Unterschiede zwischen den beiden zu erkennen.

Um mit einem Repo zu experimentieren, ohne Probleme oder Schäden zu riskieren, können Sie einen Zweig erstellen, dh eine Kopie des Repos, die Sie dann parallel ändern können. Wenn die Änderungen in der Filiale zufriedenstellend sind, können Sie die Filiale mit dem Haupt-Repo (Master) oder sogar einer anderen Filiale zusammenführen.

Beim Zusammenführen sind moderne Versionskontrollsysteme normalerweise intelligent genug, um herauszufinden, welche Änderungen von welchem ​​Zweig oder Repo aufgenommen werden sollten, je nach dem für jeden einzelnen Zweig gepflegten Änderungsverlauf. Wenn sich ein Versionskontrollsystem nicht entscheiden kann, müssen Sie einen Konflikt möglicherweise manuell lösen.

Versionskontrollsysteme Evolution

Tools zur Versionskontrolle sind bisher in drei Generationen erschienen, wobei jede Generation Flexibilität und Möglichkeiten für Parallelität bietet.

Erste Generation

Mit ursprünglichen Versionskontrollsystemen konnten zwar mehrere Personen an derselben Datei arbeiten, dies jedoch nicht gleichzeitig. Die Datei wurde gesperrt, um zu verhindern, dass andere gleichzeitig darauf zugreifen können.

Ein Beispiel für ein solches Tool ist SCCS (Source Code Control System) für die Softwareentwicklung ab 1972. RCS (Revision Control System) wurde als kostenlose Alternative zu SCCS entwickelt und bot schnelleren Betrieb, Verzweigungen und Zusammenführung (wobei immer nur ein Entwickler zu einem bestimmten Zeitpunkt an einer Datei arbeiten kann)..

Zweite Generation

Viele heute in Betrieb befindliche Versionskontrollen gehören zu dieser Kategorie. Gleichzeitige Änderungen an Dateien sind möglich, obwohl Benutzer aktuelle Revisionen in ihrer Arbeit zusammenführen müssen, bevor sie ein Commit durchführen können.

CVS (Concurrent Versions System) ist eine Instanz und ermöglicht Client / Server-Interaktionen unter Verwendung eines Repositorys. SVN (oder Apache Subversion in vollem Umfang) ist möglicherweise das beliebteste aller derzeit verwendeten Versionskontrollsysteme.

SVN kann als Neugestaltung von CVN mit einer modernen Grundlage und Lösungen für frühere CVS-Einschränkungen betrachtet werden.

Dritte Generation

Eines der bekanntesten Beispiele ist Git, auch bekannt als DVCS (Distributed Version Control Systems) mit der Möglichkeit, Zusammenführungs- und Festschreibungsvorgänge zu trennen.

Es gibt keine zentrale Basis mehr für Dateien. Verschiedene Zweige enthalten unterschiedliche Teile, wodurch die Möglichkeit eröffnet wird, auch offline an Revisionen zu arbeiten.

Ein echtes Beispiel mit Git

Wie sehen die oben beschriebenen Vorgänge bei Verwendung eines realen Versionskontrollsystems aus??

Wir nehmen hier Git als Beispiel anhand der Linux-Befehlszeile. Zuerst erstellen wir ein Git-Repository für das Verzeichnis, in dem wir uns gerade befinden. Wir verwenden den Befehl pwd, um zu sehen, wo wir uns befinden:

1
2

$ pwd

/ Benutzer / HJ / Desktop / Repos / Apps

Dann verwenden wir den Befehl git init, um das Repository (das “Master” -Repository) zu erstellen und eine Bestätigung von Git zurück zu erhalten:

1
2

$ git init

Initialisiertes leeres Git-Repository in /Users/HJ/Desktop/repos/apps/.git

Angenommen, wir fügen unserem Arbeitsverzeichnis eine neue Datei, main.c, hinzu. Wenn Sie den Befehl git status verwenden, erhalten Sie die folgenden Informationen:

1
2
3
4
5
6
7
8
9

$ git status

# Auf Zweigstellenmaster
#
# Erstes Festschreiben
#
# Nicht verfolgte Dateien:
# (verwenden "git hinzufügen …" in das einbeziehen, was begangen wird)
#
# Haupt c

Wir verwenden git add, um die Datei main.c zu verfolgen

1 $ git add main.c

Wir verwenden git commit mit einer Nachricht (Option -m) darüber, was wir tun, um Änderungen in der Datei main.c festzuschreiben.

1 $ git commit -m "Hinzufügen von main.c zum Repository"

Jetzt können wir mit dem Befehl git branch einen Zweig erstellen (z. B. “test”):

1 $ git Branch Test

Wenn Sie den Befehl git branch wieder alleine verwenden, werden einfach die Repositorys aufgelistet, die wir jetzt haben:

1
2
3

$ git branch

Prüfung

* Meister

Um mit der Arbeit an der Kopie von main.c in diesem Zweig im Zweig “test” zu beginnen, verwenden wir den Befehl git checkout, um die Bestätigung zu erhalten, dass wir jetzt im Zweig “test” arbeiten.

1
2

$ git Checkout-Test

Zum Zweig gewechselt "Prüfung"

Um zum Zweig “master” zurückzukehren, verwenden Sie einfach den Befehl “git checkout” erneut:

1
2

$ git checkout master

Zum Zweig gewechselt "Meister"

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me