# Einheit 1: Git
### Lernziele
* Hintergründe, Sinn und Zweck von Versionsverwaltung **kennenlernen**
* Git Grundlagen **kennenlernen und anwenden können**
* **Verstehen** warum Git Workflows hilfreich sind
### Warum Versionsverwaltung?
Es gibt alternative Bezeichnungen:
* Version Control Systems (VCS)
* Source Control Management (SCM)
* Revision Control Systems (RCS)
Herausforderung bei der Verwaltung von Quell-Code:
1. Software-Projekte können schnell sehr groß und unübersichtlich werden und **hunderte bzw. tausende von Code-Dateien enthalten.**
2. **Sehr viele** **Entwickler** (2, 10, hundert, oder sogar tausend) können an einem Projekt beteiligt sein.
Versionsverwaltungen können helfen diese Komplexität in den Griff zu bekommen, indem die **Änderungen an den Dateien über die Zeit hinweg protokolliert** werden.
Versionsverwaltungen lassen pro Datei die Änderungen nachvollziehen.\
Das heißt: **wer hat was wann geändert**.
So eine Historie ist auch **für einzelner Entwickler sinnvoll**:
* **Änderungen über die Zeit** nachvollziehen
* "**Zurückrollen**" zu einem bestimmten Zeitpunkt
* **Löschen** ohne Reue
Was wäre bei einem Entwickler die Alternative?
Viele (sehr viele) Kopien einer Datei anfertigen: jeden Tag, nach jeder Änderung. Wie werden die Änderungen protokolliert? Wie kann man das bei sehr vielen Dateien praktikabel gestalten.
Bei mehreren Entwicklern kommen weitere Herausforderungen hinzu:
* Wie kommen die anderen -Entwickler
* Wie kann man sehen, we**r welche Änderungen** gemacht hat
* Wie lassen sich Konflikte auflösen, **wenn mehrere Entwickler Änderungen an der gleichen Datei** (insb. der gleichen Zeile) durchgeführt haben?
Was wäre die Alternative? Code-Dateien per E-Mail verschicken?
**Versionierung** von Quell-Code erlaubt all die zuvor genannten Probleme zu lösen, außerdem lässt sich der
* **Zustand eines Projekts wiederherstellen**: zum **Testen**, für ein **Release** oder um die Einführung eines Fehlers zu finden bzw. den Bug zu beheben.
#### Was nutzen Entwickler?
### Eine kurze Geschichte von Git
* Linux Community nutzte BitKeeper zur Verwaltung des Kernel Source Codes
* Durch Lizenzänderung des Herstellers konnte BitKeeper nicht mehr genutzt werden
* Linus Torvalds wollte ein System, das ähnlich BitKeeper funktionierte, aber die Nachteile der anderen Systeme nicht mehr aufwies (z.B. lange Zeiten bei Branches durch Kopieren aller Dateien)
* Innerhalb weniger Tage wurde die erste Version von Git entwickelt:
* April 2005 Ankündigung des Projektes
* April 2005 Self-Hosting des Projektes
* Juni 2005 wurde der Linux 2.6 Kernel bereits durch Git verwaltet
#### Git Grundlagen
* *Git Repository*: Vereinfacht ausgedrückt, ein Verzeichnis, in dem die Dateien “überwacht” werden
* Metadaten (einschl. der Historie) werden in einem versteckten Unterverzeichnis `.git` verwaltet.
* Git ist eine verteilte Versionsverwaltung
* Keine Notwendigkeit eines zentralen Repositories
* *Clonen* bzw. *Forken* eines Repositories legt eine vollständige Kopie an. Änderungen können dann in das ursprüngliche Repository zurückgeführt (engl. merge) werden.
* Jede Datei in dem überwachten Verzeichnis, befindet sich in einem bestimmten Zustand:
#### Nützliches für den Einstieg
**Lokale Änderungen** anzeigen (engl. unstaged changes): `git diff [dateiname]`
**Änderungshistorie**: `git log` für Commits, `git –p log` für ein Preview
**Checkout**: Der Checkout einer früheren Version eines Repositories ersetzt alle Dateien mit dieser Version (time travel)
**Branches**: Alle Änderungen werden in dem Branch (dt. Zweig) gespeichert ohne den Hauptzweig (engl. master od. main branch) zu beeinflussen („kaputt zu machen“)
**Remote**: “Entfernte“ Kopie eines Repositories (z.B: GitLab, GitHub) – Achtung: Selbst auf GitLab/GitHub ist nicht das zentrale Repository, sondern nur eine entfernte Kopie Synchronsiation mit dem lokalen Repository z.B. mit `git push`, `git pull`
**Stash**: Änderungen, die noch nicht committet wurden, können mit `git stash` „zwischengespeichert“ und mit `git stash apply` wieder hergestellt werden
**Fork**: Server-seitiger Clone eines Repositories (vorrangig auf GitHub genutzt)
#### Git Workflows
Trotz oder gerade wegen der verteilten Verwaltung kann so einiges schief gehen. Auch wen auf dem main bzw. master immer zurückgerollt werden kann, gilt:
Das Team hält sich an spezielle Regeln, **wann neue Branches erzeugt werden** und wann diese wieder **zurück in den master bzw. main gemerged werden** dürfen.
Das Ziel ist immer das gleiche: **Der master bzw. main soll zu jeden Zeitpunkt stabil sein**, d.h. im besten Fall für den fehlerfreien Build einer aktuellen und lauffähigen Software verwendet werden können.
Dabie gibt es verschiedene Ansätze für Git Workflows.
* Centralized Workflow
* Feature Branch Workflow
* Gitflow
* Fork & Merge
* Microsoft Git Branching Strategy
In GitOps wird ein anderer Ansatz verfolgt: Hier werden möglichst alle Änderungen direkt im master/main durchgeführt. Dies ist aber nur durch einen sehr hohen Grad an Automatisierung im Build- und Testprozess möglich. Teaser: Das wird in der Vorlesung DevOps behandelt und spielt zunächst keine Rolle für uns.
### Weiterführendes Material
#### Git
* Git Command-line Tool:
* GitHub:
* GitLab:
* The case for Git in 2015:
* Pro Git Book:
* **Udacity Kurs:** [**https://www.udacity.com/course/version-control-with-git--ud123**](https://www.udacity.com/course/version-control-with-git--ud123)
* Git User‘s Manual:
* Git – SVN Crashcourse:
* Learn Git in Y minutes:
* Coding Blocks Podcast: Comparing Git Workflows:
* Gitflow Cheatsheet:
* Gitflow:
* Atlassian‘s Gitflow Zusammenfassung:
* Microsoft Recommendation:
* Git Workflows:
* Git Spiel Oh my Git! :
* Auschecken von Commits:
* Wenn was schief geht:
* Learn Git Branching:
#### Misc
* One Does not simply walk into Mordor Meme:
