.. _Git: ####################### Git: Versionsverwaltung ####################### .. index:: single: Git ********* Übersicht ********* Das Versionsverwaltungssystem namens :program:`Git` ermöglicht die gemeinschaftliche Arbeit an dem Quelltext des Werkes sowie den Austausch der Beiträge zwischen den Autoren untereinander und der Nachvollziehbarkeit der Änderungen. Somit ist es auch ein wichtiges Werkzeug um Änderungen zu begutachten und zu diskutieren und damit eine Qualitätssicherung im Team zu bewerkstelligen. Auch hier gibt es im Wesentlichen 3 wichtige Dinge zum kennenlernen: - Die Datenbank (Repository) - Beiträge (Commits) - Zweige :program:`Git` basiert im Grunde auf aufeinander aufbauenden Einträgen, d. h. die jeweiligen Änderungen werden in Git eingetragen und Git speichert dabei immer die Änderungen im Bezug auf die \*vorige Version. Somit bilden sich Ketten von immer auf den Vorgänger verweisenden Einträgen (Beiträgen, **Commits**) mit Änderungen. Diese Ketten von Beiträgen können sich aufzweigen, wenn z. B. zwei Autoren unterschiedliche Änderungen ausgehend von einer gemeinsamen Basis vornehmen. Um diese klassiche Situation abzubilden gibt es **Zweige**. Sie ermöglichen das parallele und gleichzeitige Bearbeiten des Werkes durch unterschiedliche Personen unabhängig voneinander. Diese Zweige können selbstverständlich auch wieder *zusammengeführt* werden (*merge*). Im Idealfall werden dann die unterschiedlichen Änderungen der jeweiligen Autoren miteinander kombiniert und es entsteht wieder eine einheitliche Fassungmit den Beiträgen der beteiligten Autoren. Natürlich kanne s beim Zusammenführen aber auch zu Konflikten kommen, wenn z. B. zwei Autoren die gleiche Stelle im Werk bearbeitet haben. Dann obliegt es einem Beauftragtem die Konflikte sinnvoll zu lösen und eine bereinigte Fassung zu erstellen. Ein **Repository** (Verzeichnis) ist im Prinzip eine *Datenbank* in welcher die jeweiligen Einträge verzeichnet sind. .. index:: single: Repository single: Arbeitsordner single: .git ********************************** Das *Repository* ist die Datenbank ********************************** Die Versionierungsdatenbank eines mit Git versionierten Projektes wird als *Git-Verzeichnis*, *Git-Repository* oder kurz einfach **Repository** bzw. **Repo** bezeichnet. Für den Endanwender besteht ein Repo aus zwei Dingen: 1. **Arbeitsordner**: Hier befinden sich die Projektdateien zu einem von Benutzer bestimmten Vewrsionstand. Änderungen an Dateien werden in diesem Projektverzeichnis auf die übliche Weise vorgenommen. 2. :file:`.git`\ **-Ordner** bzw. die eigentliche **Git-Datenbank**: Die Datenbank, in welcher die Versionsinformationen gespeichtert werden, befinden sich immer im ``.git``-Unterordner des Arbeitsordners. Mit diesem Order hat der Benutzer eigentlich nichts zu tun, er darf jedoch natürlich nciht gelöscht werden. Es kann mehrere dieser Datenbanken für das gleiche Projekt geben, welche untereinander ihre Daten austauschen und sich somit gegenseitig auf dem aktuellen Stand halten. Im Prinzip kann jeder Autor auf seinem Computer eine solche Datenbank haben (auch mehrere) und mit anderen, entfernten Datenbanken, Beiträge austauschen. Unser Projekt hat eine zentrale Datenbank namens ``origin`` eingerichtet, dorthin schicken die Autoren ihre Beiträge, bzw. laden die Beiträge von anderen Autoren herunter. Ein Repository besteht (normalerweise) nicht nur aus der Datenbank, sondern auch aus einem **Arbeitsverzeichnis**. Dieses stellt den Stand einer Fassung zu einem defnierten Zeitpunkt dar (bzw. zum Zeitpunkt eines definierten Beitrags). Git kann angewiesen werden, das Arbeitsverzeichnis gemäß eines beliebigen Punkts in der Versionsgeschichte der Datenbank einzustellen (*auschecken*, *Checkout*). Anschließend können die Dateien und Dokumente im Arbeitsverzeichnis bearbeitet werden. Git erkennt sodann alle Änderungen an den Dateien im vergleich zur urprünglich eingestellten Version. Diese Änderungen können dann als Beiträge in die Datenbank eingetragen werden (*committed*). Das Arbeitsverzeichnis dient somit dem Bearbeiten von Einträgen und damit dem Erstellen neuer Einträge in die Datenbank. .. index:: single: Commit single: Eintrag single: Beitrag ************************ Commits (Ein-/ Beiträge) ************************ Doch wie werden nun die Versionsinformationen gespeichert bzw. aufgezeichnet? Hierfür vergleicht Git den Stand der Dateien im Projektordner mit dem zuletzt gespeichterten Stand in der Datenbank und zeigt geänderte Inhalte an. Der Benutzer kann nun Änderungen in *Einträge* (**Commits**) zusammenfassen, mit einer Beschreibung versehen und in die Datenbank eintragen lassen (**committen**). Jeder Commit besteht aus einem Beschreibungstext, einer Prüfzahl und den *Änderungen gegenüber dem vorigen Commit*. Das bedeutet, jeder Commit speichert nur die Änderungen und nicht den kompletten Projektordner, und baut daher immer auf dem vorhergehendem Commit auf. es ergibt sich somit ein Baum von Einträgen, vom allerersten Eintrag bis zum letzten Commit. .. index:: single: Zweige single: Branch ****** Zweige ****** Der eigentlich Clou sind die Zweige. Stellen wir uns ein kleines Repo mit 3 Commits (A, B und C) vor: :: A→B→C Weiters haben wir 2 Autoren (X, Y), welche im Versionstand C unabhängig voneinander Änderungen vornehmen (X1, X2 bzw. Y1, Y2, Y3), dies würde in etwa so aussehen: :: A ─ B ─ C ─ X1 ─ X2 │ └── Y1 ─ Y2 ─ Y3 Somit haben wir nun 2 konkurrierende Versionlinien: X2 und Y3. Wir sehen dass beide Versionslinien auf C aufbauen und sich dann -- *verzweigen*. Somit werden diese Versionslinien **Zweige** genannt. Natürlich möchten wir diese Zweige miteinander vereinigen, dies wir ein Redakteur erledigen, nachdem er die Änderungen geprüft hat -- Doch davor haben wir noch eine andere Herausforderung, wir müssen diese Zweige bennenen. Somit bekommen die Commits der Zweige ein Namensschild mit einem Namen, in unserem Fall benennen wir die Zweige nach den Autoren (``Autor-X`` und ``Autor-Y``). Ein Commit eines Zweiges kann dabei auch mehrere Namensschilder haben. Dann gibt es noch einen besonderen Zweig namens ``master``. In diesem Zweig verwaltet des Redakteur die von ihm aufgenommenen Beiträge der anderen Autoren: Am Beginn gibt es nur den ``master``-Zweig: :: ┌────────┐ │ master │ ├────────┘ │ A ─ B ─ C Dann werden für jeden Autor je ein Zweig erstellt, Commit C hat somit 3 Namensschilder: :: ┌────────┐ │ master │ ├────────┘ ├─────────┐ │ Autor-X │ ├─────────┘ ├─────────┐ │ Autor-Y │ ├─────────┘ │ A ─ B ─ C Schlußendlich bearbeiten die Autoren Ihre Zweige: :: ┌────────┐ │ master │ ├────────┘ │ ┌─────────┐ │ │ Autor-X │ │ ├─────────┘ │ │ A ─ B ─ C ─ X1 ─ X2 │ └── Y1 ─ Y2 ─ Y3 │ ├─────────┐ │ Autor-Y │ └─────────┘ Es gilt: - Jedes Commit baut auf dem Vorangegengenem auf und bildet somit einen Zweig. - Jeder Zweig hat mindestens ein Namenschild. Schließlich vereinigt der Redakteur die beiden Zweige, daraus entsteht dann das Commit D, welches die 5 Autorenbeiträge und eventuell noch vom Redaktuer vorgenommene Änderungen enthält: :: ┌─────────┐ ┌────────┐ │ Autor-X │ │ master │ ├─────────┘ ├────────┘ │ │ A ─ B ─ C ─ X1 ─ X2 ─────────── D │ │ └── Y1 ─ Y2 ─ Y3 ───────┘ │ ├─────────┐ │ Autor-Y │ └─────────┘ .. index:: single: Merge Zweige zusammenführen (*„Mergen“*) ================================== ****************** Technische Details ****************** Wikipedia contributors. (2019, June 21). Git. In Wikipedia, The Free Encyclopedia. Retrieved 10:35, June 23, 2019, from `https://en.wikipedia.org/w/index.php?title=Git&oldid=902826917 `_ Seite „Git“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 23. Mai 2019, 06:47 UTC. URL: `https://de.wikipedia.org/w/index.php?title=Git&oldid=188859677 `_ (Abgerufen: 23. Juni 2019, 10:41 UTC) Git. (2018, September 16). Wikibooks, The Free Textbook Project. Retrieved 10:46, June 23, 2019 from `https://en.wikibooks.org/w/index.php?title=Git&oldid=3464901 `_. Git ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiiert wurde. Git ist ein verteiltes Versionsverwaltungssystem, das sich in einigen Eigenschaften von typischen Versionsverwaltungssystemen unterscheidet: