Commit fa9f7f72 authored by Lukas Nagel's avatar Lukas Nagel
Browse files

write github workflow section

parent e9852d4a
......@@ -319,20 +319,22 @@ Auch wenn zwei Dateien beziehungsweise Verzeichnisse den selben Inhalt haben,
muss nur ein Satz Objekte gespeichert werden.
Weiterhin ändert sich am blob Objekt einer Datei beim Umbenennen nichts,
nur das tree Objekt wird modifiziert.
Dieses Konzept wird als *Deduplizierung* bezeichnet.
Dieses Konzept wird als *Deduplizierung* bezeichnet [@haenel2015, S. 37].
Dies Bedeutet aber auch das falls sich nur ein sehr kleiner Teil einer großen
Datei ändert,
werden zwei nahezu identische Objekte mit unterschiedlichem Hash angelegt.
Dies erfordert somit überproportional viel Speicher,
weswegen der Objektspeicher mittels *Deltakompression* komprimiert wird.
weswegen der Objektspeicher mittels *Deltakompression* komprimiert wird
[@chacon2014].
Der Hash eines tree Objektes wird auch über die Hashes der enthaltenen
tree und blob Objkete gebildet.
Und der Hash jedes Commit Objektes wird unter anderem über die Hashes
des tree Objektes und der Vorgänger Commits gebildet.
Somit ergibt sich eine Kette kryptographischer Hashes, wodurch die *Integrität*
des Projektverzeichnisses und der gesamten Versionsgeschichte sicherstellt wird.
des Projektverzeichnisses und der gesamten Versionsgeschichte sicherstellt wird
[@haenel2015, S. 42].
Dadurch das ein Commmit mehrere Vorgänger hat lässt sich die Versionsgeschichte
als gerichteter Graph ohne Zyklen (*DAG*) betrachten.
......@@ -344,7 +346,8 @@ Hash bereits bekannt sein müsste.
Die Knoten, wie in Abbildung \ref{fig:graph} zu sehen, entsprechen den Commits
und die Vorgänger Beziehung ist durch die Kanten ausgedrückt.
Zweige entsprechen in diesem Modell Zeigern auf Commits.
Das Verständnis vieler Operationen wird durch dieses Modell vereinfacht.
Das Verständnis vieler Operationen wird durch dieses Modell vereinfacht
[@haenel2015, S. 41].
![Exemplarischer Versionsgraph](../grafiken/example-graph.pdf){#fig:graph}
......@@ -361,7 +364,8 @@ in den Index übernommen und benötigte Objekte erstellt.
Mit der Reset Operation können Inhalte aus dem Repository in den Index
und optional in das Arbeitsverzeichnis übernommen werden.
Somit lässt sich die nächste Version inkrementell erstellen
und muss nicht dem Zustand des Arbeitsverzeichnisses entsprechen.
und muss nicht dem Zustand des Arbeitsverzeichnisses entsprechen
[@chacon2014].
Verzweigungen in Versionsgraph sind in Git sehr performant Umgesetzt.
Eine neuer Zweig erfordert lediglich das anlegen einer neuen Referenz,
......@@ -415,13 +419,13 @@ Diese Objekte enthalten Ähnlich dem Commit neben der Referenz auf ein Objekt
Informationen zum Ersteller, Datum und eine Beschreibung.
Ein Tag muss nicht zwingend auf einen Commit zeigen,
das wohl prominenteste gegenbeispiel wäre Junio Hamanos GPG-Schlüssel
als blob Objekt im `git.git` Repository.
als blob Objekt im `git.git` Repository [@chacon2014].
Git ist ein *verteiltes* Versionsverwaltungssystem,
weshalb jeder nicht nur einen Schnappschuss des Projekts herunterlädt sondern
das Repository mit der gesamten Versionsgeschichte.
Somit werden viel Operationen schneller, da kein Austausch über das Newtwerk
Notwendig ist.
Notwendig ist [@haenel2015, S. 149].
In der Regel gibt es für ein Projekt ein Hauptrepository mit dem sich
Mitwirkende synchronisieren.
So ein entferntes Repository wird *Remote* genannt und zu einem lokale Projekt
......@@ -430,7 +434,8 @@ Die Remotes werden über einen Zugewiesen Namen identifiziert, wenn man einen
Remote mittels der Clone Operation kopiert wird dieser Standardmäßig als
`origin` angelegt.
Einem lokalen Zweig kann sein Pendant auf dem Remote zugewiesen werden,
dieser wird als *Upstream-Branch* bezeichnet, häufig ist dies der Gleichnamige.
dieser wird als *Upstream-Branch* bezeichnet, häufig ist dies der Gleichnamige
[@chacon2014].
Um Änderungen an einen Remote zu senden, stellt Git die Push Operation bereit.
Hier wird zunächst mit dem Remote ausgehandelt welchen Objekte hochgeladen
......@@ -441,7 +446,8 @@ von der Spitze des lokalen aber nicht des Upstream Zweiges erreichbar sind.
Ist der Spitze des Upstream Zweig nicht Vorgänger des Lokalen Zweiges,
so ist kein Vorspulen möglich und die Operation schlägt fehl.
In diesem Fall müssen die Änderungen die bereits auf dem Remote wurden aber
noch nicht lokal eingepflegt wurden, heruntergeladen und integriert werden.
noch nicht lokal eingepflegt wurden, heruntergeladen und integriert werden
[@chacon2014].
Die Änderungen werden mit der Fetch Operation heruntergeladen, aber noch
nicht mit dem lokalen Zweig zusammengeführt.
......@@ -451,15 +457,70 @@ als `orign/master` verfügbar.
Somit kann der lokale mit dem entfernte Zweig auf die selbe Weise wie lokale
Zweige zusammengeführt werden.
Die Pull Operation vereinfacht diesen Schritt, indem sie die Fetch mit einer
Merge Operation verbindet.
## TODO: Der Charakteristische GitHub Arbeitsablauf
Merge Operation verbindet [@haenel2015, S. 149].
Neben diesen Operationen stellt Git weitere Funktionen zum aus- und einlesen
von Änderungen die dann auf verschiedenste weise Ausgetauscht werden können.
Diese Operationen erlauben eine Vielzahl von Arbeitsabläufe mit Git.
So werden beispielsweise Änderungen des Linux Kernel an dessen Mailing Liste
geschickt und dort diskutiert, nachgebessert und eventuell abgelehnt oder
eingepflegt [@hamano2006].
Für Projekte auf GitHub hat sich ein neuer Ablauf durchgesetzt, der auf die
GitHub typischen Mechanismen Fork und Pull-Request setzt.
Da ein Projekt auf GitHub in Namensraum eines Nutzer abgelegt ist,
kann sehr einfach eine Kopie im Namensraum eines anderen Nutzers angelegt
werden.
Dies wird als *Fork* bezeichnet und sollte nicht mit dem Gleichnamigen
Abspalten nach Uneinigkeit verwechselt werden [@blishak2016],
vergleiche Abbildung \ref{fig:ghwf} Schritt 1.
Von diesem Forke kann nun eine lokale Kopie angelegt werden (Schritt 2)
und Änderungen eingepflegt werden (Schritt 3).
Sollen diese nun in das Projekt eingepflegt werden, von dem die Kopie erstellt
wurde, so kann, nachdem die Änderungen veröffentlicht wurden (Schritt 4),
eine *Pull Request* geöffnet werden (Schritt 5).
Diese kann dann vom Eigentümer des Projekts als entfernter Branch
heruntergeladen, inspiziert und bearbeitet werden (Schritt 6).
Das Zusammenführen einer Pull Request kann lokal mittels einer Merge Operation
oder auf der Weboberfläche durchgeführt werden (Schritt 7 & 8).
Auf letzterer können die Änderungen auch Diskutiert und gegebenenfalls
abgelehnt werden.
![Typischer GitHub Arbeitsablauf](../grafiken/github-workflow.pdf){#fig:ghwf}
## TODO: Automatisierung mittels Actions
## TODO: Technische Voraussetzungen
* Textdateien, Problem mit binär Dateien
* Speicher Begrenzung von GitHub
Theoretisch gibt es keine Beschränkung welche Dateien Versioniert werden können,
Git speichert den Inhalt jeder Dateiversion auf die Gleiche weise,
nämlich als Schnappschuss in einem blob Objekt [@hamano2006].
Der Informations Gewinn ist bei binär Dateien im Vergleich zu Zeilen
Orientierten Textdateien geringer,
da die Unterschiede zwischen den Inhalten nicht Sinnvoll darstellbar sind.
Natürlich gibt es hier Ausnahmen, beispielsweise können für Bilder die Pixel
angezeigt werden, die sich geändert haben [@haenel2015, S. 226].
Artefakte die aus dem versionierten Quellcode erzeugt werden,
wie zum Beispiel PDF Dokumente oder Java Class Dateien sollten selbst nicht
versioniert werden.
Dies liegt daran, dass diese sich in sehr häufig ändern und Änderungen in
solchen binär Dateien häufig, wegen Kompression, statistisch verteilt sind.
Dadurch wird die Kompression der Versionsgeschichte mittels Deltakompression,
erschwert, schließlich umfassen so die Deltas fast den gesamten Inhalt
[@chacon2014].
Generell können daher sich selten Ändernde Binär Dateien, wie beispielsweise
Logos oder Icons in das Repository aufgenommen werden.
Ein weiter Aspekt der beachtet werden sollte, ist dass wenn jemand an dem
Projekt Mitwirken möchte dieser das Gesamte Repository herunterladen muss
und daher darauf geachtet werden sollte, die Größe so klein wie Möglich zu
halten.
Eine Möglichkeit Große Dateien erst bei Bedarf herunterzuladen bietet das
von GitHub entwickelte *LFS* (Large File Storage) System.
Diese ist in der Kostenlosen Variante jedoch auf 2GB pro Datei
beschränkt und ist daher für einige Anwendungen ungeeignet [@herron2019].
Weitere Möglichkeiten, die keinen zentralen Server benötigen
sind `git-annex` oder `git-portal`.
Für Projekte die auf GitHub veröffentlicht werden sollen gibt es weiterhin die
Einschränkung, dass höchstens 100MB pro Push Operation übertragen werden dürfen.
## TODO: Offene Enden
* Unterschiedliche Ausführungskontexte => Docker
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment