**Git**: Versionskontrolle
########################################################################

.. admonition:: Synopsis

    Ein Versionskontrollsystem (VCS) verfolgt den Verlauf von Änderungen, wenn mehrere Personen gemeinsam an einem Projekt arbeiten.
    Moderne Versionskontrollsysteme erlauben
    **parallele Änderungen**
    in **Zweigen** (**Branches**)
    und bringen Mechanismen mit,
    die ein geordnetes und möglichst einfaches **Zusammenführen** (**Mergen**)
    der Änderungen/Beiträge ermöglichen.
    Während der Entwicklung können Änderungen
    mit der Gewissheit vorgenommen werden,
    dass jede Änderung **nachvollziehbar** und
    jede Version jederzeit **wiederherstellbar** ist.
    :program:`Git` ist ein Beispiel für ein solches Versionskontrollsystem.
    Die Datenbank der Versionsverwaltung wird **Repository** genannt.

.. rubric:: Querverweis

-   Weitere Informationen zum Versionskontrollsystem Git finden sich im Abschnitt :ref:`Git`.

.. figure:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-003.png

    Auszug aus dem Versionsverlauf

Grundlegende Funktionen
************************************************************************

Aufgabe eines Versionsverwaltungssystems ist einerseits die Archivierung und **Nachvollziehbarkeit** von Änderungen, sowie das möglichst problemlose und automatische **Zusammenführen** von Beiträgen.

Die AASS verwenden :program:`Git` als Versionsverwaltungssystem,
welches zusammen mit der :ref:`Projektzentrale GitLab™ <Thema-Gitlab>` ein komfortables Management der Beiträge und Änderungen ermöglicht.

Dazu beherrscht es folgende grundlegende Funktionen und Konzepte:

1.  Aufeinander aufbauende Änderungen bzw. Beiträge: **Commit(s)**.

    .. image:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-Commit.png
2.  Aus der Aneinanderreihung der Commits ergibt sich der **Versionsverlauf**.

    .. image:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-Versionsverlauf-001.png
3.  Jedes Commit stellt einen Zustand des **Arbeitsverzeichnis**, in dem sich die Dateien bzw. Dokumente des Projekts befinden, zu einem bestimmten Zeitpunkt dar.
4.  Das Arbeitsverzeichnis kann durch **auschecken** in den Zustand eines jeden beliebigen Commits versetzt werden.
5.  Umgekehrt können Änderungen, die an Dateien im Arbeitsverzeichnis vorgenommen werden, als **neues Commit eingetragen** und damit dem Versionsverlauf hinzugefügt werden.
6.  Die Commits werden in einer Datenbank, dem **Repository**, gespeichert.
7.  Der Versionsverlauf kann sich, ausgehend von einem Versionsstand, (Commit) in Zweige (**Branches**) aufzweigen.
    Somit können unabhängig voneinander Änderungen durchgeführt werden.

    .. image:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-Branchen.png
8.  Zwei oder mehrere Branches (Zweige) können durch einen **Merge** wieder zusammengeführt (*gemerged*) werden.

    .. image:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-Merge.png
9.  Mittels eines **Merge Requests** (*"Bitte merge meinen Zweig in Deinen Zweig!"*) können Änderungen vor dem Zusammenführen diskutiert werden.

.. figure:: /Bilder/Screenshots/Git/Screenshot-Git-Ccca-002.png

    Auszug aus dem Versionsverlauf

    Jeder Punkt symbolisiert ein Commit, die Linien sind Branches.
    Wo zwei Linien wieder zusammenkommen erfolgte ein *Merge*.



Exkurs: *Warum* Versionskontrolle?
************************************************************************

Wenn Sie ("Max") jemals im Team
an irgendetwas Digitalem zusammengearbeitet haben,
dann wissen Sie, wie es geht:

	Es beginnt ganz einfach:
	Sie haben Ihre Version
	(``Dokument-Entwurf.doc``)
	eines Dokuments
	und senden sie an einen Partner ("Moritz").
	Dieser nimmt einige Änderungen vor (``Dokument-Entwurf-2.doc``),
	sodass es jetzt zwei Versionen gibt,
	und sendet die Vorschläge an Sie zurück.
	Sie integrieren ihre Änderungen in Ihre Version,
	und jetzt gibt es eine neue, konsolidierte Version (→ ``Dokument-Entwurf-eingearbeitet``).

	Dann wird es schlimmer:
	Während Sie Ihre Version weiter ändern (→ ``Dokument-Entwurf-3.doc``),
	nimmt Ihr Partner weitere Änderungen an seiner Version vor
	-- und nennt diese auch ``Dokument-Entwurf-3.doc``.
	Jetzt haben Sie drei Versionen:

	-	``Dokument-Entwurf-eingearbeitet``:
		Die zusammengeführte Kopie,
		an der Sie beide gearbeitet haben,
	-	``Dokument-Entwurf-3.doc``:
		Die Version, die Sie weiter geändert haben
	-	``Dokument-Entwurf-3.doc``, die Ihr Partner geändert hat
		(gleicher Name,
		er weiss ja nicht
		dass Sie zwischenzeitlich weitergebarbeitet haben ...).

	Gut, man kann ja die Dateien besser benennen,
	also z. B. mit Autorennamen und Datum:

	-	``Dokument-Max-2020-04-01.doc``
	-	``Dokument-Moritz-2020-04-01.doc``

Sprung in die Zukunft:

	Max war fleißig und hat einige Revision vorgenommen und hat nun folgende Dateien:

	-	``Dokument-Max-2020-04-01.doc``
	-	``Dokument-Max-2020-04-09.doc``
	-	``Dokument-Max-2020-04-15.doc``
	-	``Dokument-Max-2020-04-15-2.doc``
	-	``Dokument-Max-2020-04-21.doc``

	Jede dieser Änderungen hat er Moritz zur Kenntnisnahme geschickt.

	Am 22. April bekommt er dann von Moritz eine überarbeitete Version
	``Dokument-Moritz-2020-04-22.doc``.
	Aber welche Version hat Moritz überarbeitet?
	Die vom 1., 9., 15. (1 oder 2?) oder vom 21.?
	Dazu kommt dann von Markus die Version
	``Dokument-Markus-2020-04-17.doc``,
	in welcher er im gesamten Dokument Rechtschreibfehler korrigiert hat.

Möchten Sie nun die Änderungen zusammenführen?

	--- (Nein!)