Commit 665c7212 authored by Lukas Nagel's avatar Lukas Nagel
Browse files

fix typos

parent 2ccec84c
Pipeline #142541 passed with stages
in 12 minutes and 14 seconds
......@@ -10,7 +10,7 @@ abstract: |
Änderung und wann vollzogen hat.
Git bietet dazu einen Mechanismus Versionen mit Informationen zum Autor,
Zeit und einer Beschreibung anzulegen.
GitHub bietet auf den Git Mechanismen aufbauend eine Plattform zum
GitHub bietet, auf den Git Mechanismen aufbauend, eine Plattform zum
auszutauschen von Änderungen sowie zum veröffentlichen von Projekten.
Dies ermöglicht eine einfache Zusammenarbeit an Projekten
und Zugang zu Informationen.
......@@ -68,15 +68,16 @@ Für den Beweis wollen sie ein Dokument mit LaTex verfassen
und der Algorithmus soll in Python implementiert werden.
Dafür fallen die Dateien `proof.tex` und `alog.py` an.
Beide möchten unabhängig an dem Projekt arbeiten, Fortschritte miteinander
teilen und eine Version zentral verfügbar haben um von Unterschiedlichsten
teilen und eine Version zentral verfügbar haben um von unterschiedlichsten
Geräten zu arbeiten.
Sie verwenden dazu Git und GitHub, da es einfach ist mit Git herauszufinden
was der andere an dem Projekt verändert hat und mittels GitHub können sie
sich austauschen.
Zusätzlich können sie mittel GitHub Actions das LaTex Dokument automatisch
kompilieren und so immer auf die PDF Version zugreifen und automatische
Tests laufen lassen, so das sicher gestellt ist, dass der Algorithmus
korrekt ist beziehungsweise zu sehen welche Fälle noch nicht funktionieren.
Zusätzlich können sie mit GitHub Actions das LaTex Dokument automatisch
kompilieren und so immer auf die PDF Version zugreifen.
Außerdem können sie automatische Tests laufen lassen, so das sicher gestellt ist,
dass der Algorithmus korrekt ist beziehungsweise zu sehen welche Fälle noch
nicht funktionieren.
Alice legt nun ein Projekt auf GitHub an und beide laden sich das Repository
herunter.
......@@ -102,7 +103,7 @@ Dokumentation kann dann über Benachrichtigungen oder Notizen geschehen.
Solch ein Ablauf kommt schnell an seine Grenzen,
da hoher Aufwand an Koordination gepaart mit der Notwendigkeit von Konventionen
da hoher Aufwand an Koordination gepaart mit der Notwendigkeit von Konventionen,
ein Massives Risiko für Fehler birgt.
Daher ist es nützlich Koordination und Konventionen
mittels Werkzeugen, sogenannten Versionsverwaltungssysteme (*VCS*),
......@@ -113,8 +114,8 @@ Mitwirkende holen sich von diesem die aktuellste Version,
auch *checkout* genannt, nehmen Änderungen vor und laden diese
wieder hoch, auch *checkin* oder *commit* genannt.
Der Server speichert dann diese neue Version so,
dass Vorherige erreichbar bleiben,
die Gesamtheit der Versionen wird als *Versionsgeschichte* bezeichnet
dass Vorherige erreichbar bleiben.
Die Gesamtheit der Versionen wird als *Versionsgeschichte* bezeichnet
und im *Repository* gespeichert.
......@@ -138,12 +139,12 @@ Git gehört zu den *verteilten* Versionsverwaltungssystemen,
bei denen jeder eine Kopie des Gesamten Repository lokal gespeichert hat.
Weiterhin wird für jede Version ein Schnappschuss des gesamten Projektes
gespeichert und nicht nur wie bei anderen üblich die Unterschiede,
dadurch lassen sich Zustände sehr effizient wiederherstellen.
dadurch lassen sich Zustände sehr effizient wiederherstellen [@hamano2006].
Dies erfordert bei größeren Projekten mehr Bandbreite und Speicher,
was durch einen sogenannten *shallow* clone umgangen werden kann.
Weiterhin ist dieser Nachteil angesichts heutiger
Übertragungsgeschwindigkeiten und Speicherkapazitäten oft vernachlässigbar
[baerisch2005].
[@baerisch2005].
Lokale Repositories können untereinander synchronisiert werden,
......@@ -163,7 +164,7 @@ besser nachvollziehbare Reihenfolge zu bringen [@haenel2015, S. 126].
Ähnlich zu einem eigenen Entwicklungskontext pro Nutzer,
erlaubt *branching* einen eigenen Kontext pro Feature.
Aus der Perspektive des Nutzers sind Zweige alleinstehende des Projektes
Aus der Perspektive des Nutzers sind Zweige alleinstehende Kopeien des Projektes
[@baerisch2005].
Dabei wird von einen Hauptzweig,
nach git *Konvention* `master`,
......@@ -193,7 +194,7 @@ mittels einer Anfrage, der sogenannten *Pull Request*, übernommen.
Der Name leitet sich von einem Git Kommando ab,
das zum erstellen einer Anfrage per E-Mail verwendet werden kann.
Der Austausch über E-Mail wird von einigen großen Projekten,
wie zum Beispiel Git selbst, verwendet [@haenel2015, S. 179],
wie zum Beispiel Git selbst, verwendet [@hamano2006]
wird aber nicht von GitHub unterstützt.
Neben der Webbasierten grafischen Oberfläche vereinfacht dies,
das einpflegen von Änderungen in Open Source Projekte,
......@@ -203,7 +204,7 @@ verglichen mit früheren Ansätzen.
Der Fokus auf Software Entwicklung in GitHub,
prägt sich ebenfalls in der Integration von CI/CD Werkzeugen.
spiegelt sich ebenfalls in der Integration von CI/CD Werkzeugen.
Diese können verwendet werden um Tests auszuführen
und ausführbare Pakete zu erstellen.
Die Ergebnisse von Test können in Pull Request integriert werden
......@@ -216,7 +217,8 @@ dies erfordert aber eine Individuelle nicht standardisierte Konfiguration
und einen eigenen Server.
GitHub nutzt zur Bereitstellung ihrer Dienste, im Gegensatz zu GitLab oder SourceForge,
GitHub nutzt zur Bereitstellung ihrer Dienste,
im Gegensatz zu GitLab oder SourceForge,
selbst nicht Quelloffene und unter proprietärer Lizenz stehende Software,
sodass eine eigene Instanz lediglich Kunden von GitHub Enterprise möglich ist.
......@@ -256,7 +258,7 @@ und GitHub bietet eine kostenlose Plattform zur Veröffentlichung.
Dabei kann es zu übertragungsproblemen kommen oder auf sonstige Weise
sich Daten ändern.
zu veränderten Daten.
Ebenfalls könnten Antagonisten versuchen die Versionsgeschichte
so zu verändern, dass zum Beispiel Schadsoftware ausgeführt wird.
Dies soll erkannt werden, damit die *Integrität* gewährleistet ist.
......@@ -285,9 +287,9 @@ Instanzen des universellen Datentyps *Objekt*,
gespeichert.
Objekt können sich als *tree*, *commit* oder *blob* Objekte ausprägen.
Die Ausprägung wird als Text am Anfang der Datei festgelegt.
Das blob Objekjt speichert beliebige Byte folgen,
Das blob Objekt speichert beliebige Byte folgen,
wie in der Regel den Inhalt von Dateien.
Tree Objekte bilden einen Datei- oder Verzeichnisnamen
Tree Objekte bilden die Datei- oder Verzeichnisnamen eines Verzeichnisses
auf die Referenz des entsprechenden blob beziehungsweise tree Objektes.
Das commit Objekt wird für jede Revision angelegt
und enthält den Namen und die E-Mail des Autors,
......@@ -301,8 +303,8 @@ wobei die Vorgänger den Spitzen der zusammenzuführenden Zweige entsprechen
[@haenel2015, S. 50].
In Abbildung \ref{fig:objm} ist der Zusammenhang der Objekt Arten mit der Verzeichnisstruktur
schematisch dargestellt.
In Abbildung \ref{fig:objm} ist der Zusammenhang der Objekt Arten mit der
Verzeichnisstruktur schematisch dargestellt.
![Git Objektmodell](../grafiken/git-object.pdf){#fig:objm}
......@@ -322,22 +324,22 @@ Weiterhin ändert sich am blob Objekt einer Datei beim Umbenennen nichts,
nur das tree Objekt wird modifiziert.
Dieses Konzept wird als *Deduplizierung* bezeichnet [@haenel2015, S. 37].
Dies Bedeutet aber auch das falls sich nur ein sehr kleiner Teil einer großen
Dies Bedeutet aber auch, dass falls sich nur ein sehr kleiner Teil einer großen
Datei ändert,
werden zwei nahezu identische Objekte mit unterschiedlichem Hash angelegt.
zwei nahezu identische Objekte mit unterschiedlichem Hash angelegt werden.
Dies erfordert somit überproportional viel Speicher,
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.
tree und blob Objekte 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
[@haenel2015, S. 42].
Eine Besonderheit von Git ist der Index, oder auch *Staging Area*, genannt,
Eine Besonderheit von Git ist der Index, oder auch *Staging Area* genannt,
der als Schnittstelle zwischen Arbeitsverzeichnis und Repository fungiert.
Änderungen aus dem Arbeitsverzeichnis werden zünachst mittels der Add
Operation im Index gesammelt und mittels der Commit Operation
......@@ -360,9 +362,9 @@ Dadurch das ein Commmit mehrere Vorgänger hat lässt sich die Versionsgeschicht
als gerichteter Graph ohne Zyklen (*DAG*) betrachten.
In Abbildung \ref{fig:graph} ist ein solcher abgebildet.
Ein Zyklus ist theoretisch nicht ausgeschlossen,
aber nur erschöpfende Suche möglich, da wenn sich zwei Commits gegenseitig als
Vorgänger haben sollen, für den jeweiligen Hash der jeweils andere
Hash bereits bekannt sein müsste.
aber nur durch erschöpfende Suche möglich,
da wenn sich zwei Commits gegenseitig als Vorgänger haben sollen,
für den jeweiligen Hash der jeweils andere 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.
......@@ -394,13 +396,14 @@ Danach ist im Versionsgraphen keine Verzweigungsstruktur erkennbar,
da kein Merge-Commit angelegt wurde.
Sind auf beiden Zweigen Commits eingepflegt worden, so ist ein Merge-Commit
nötig.
Dieser erhält als Vorgänger beide Commits der Zweige und das Tree Objekt zeigt
Dieser erhält als Vorgänger die Spitzen der Zweige und das Tree Objekt zeigt
auf einen Schnappschuss in dem Änderungen beider Zweige enthalten sind.
Wurden sich überschneidende Stellen verändert, so kann Git nicht automatisch
entscheiden wie die Änderungen vereinigt werden sollen.
Daher muss dieser Konflikt manuell aufgelöst werden,
dazu können die Betroffenen Stellen in einem Textbearbeitungsprogramm
oder mit Grafische Werkzeuge, wie es zum Beispiel GitHub bereitstellt,
dazu kann der Konfilt an den Betroffenen Stellen in einem
Textbearbeitungsprogramm oder mit Grafische Werkzeuge,
wie es zum Beispiel GitHub bereitstellt,
gelöst werden.
Das effiziente Verzweigen erlaubt Arbeitsabläufe mit vielen Zweigen.
......@@ -434,13 +437,13 @@ 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
Somit werden viel Operationen schneller, da kein Austausch über das Netzwerk
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
können mehrer Remotes hinzugefügt werden.
Die Remotes werden über einen Zugewiesen Namen identifiziert, wenn man einen
können mehrere Remotes hinzugefügt werden.
Die Remotes werden über einen Zugewiesenen 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,
......@@ -453,10 +456,10 @@ werden müssen.
Dies entspricht den Objekten aller Commits,
die im kombinierten Graphen des Remotes und des Lokalen Repositories,
von der Spitze des lokalen aber nicht des Upstream Zweiges erreichbar sind.
Ist der Spitze des Upstream Zweig nicht Vorgänger des Lokalen Zweiges,
Ist die Spitze des Upstream Zweiges 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
In diesem Fall müssen die Änderungen die bereits auf dem Remote existieren,
aber noch nicht lokal eingepflegt wurden, heruntergeladen und integriert werden
[@chacon2014].
Die Änderungen werden mit der Fetch Operation heruntergeladen, aber noch
......@@ -466,11 +469,12 @@ beispielsweise wäre der `master` Zweig auf dem Remote `origin` lokal
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
Die Pull Operation beschleunigt diesen Schritt, indem sie die Fetch mit einer
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.
von Änderungen bereit, welche 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
......@@ -487,7 +491,7 @@ 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)
Von diesem Fork 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),
......@@ -505,16 +509,16 @@ GitHub bietet neben reinem Projekt Hosting eine Vielzahl von Diensten,
die den Entwicklungsprozess unterstützen.
So lassen sich bei bestimmten Ereignissen wir etwas einer Push Operation
oder Pull Request automatisch Programme ausführen, sogenannte Actions.
Diese können verwendet werden um eine Binär Datei zu Kompilieren und somit
ohne das sie ins Repository aufgenommen wurde verfügbar machen
Diese können verwendet werden um eine Binär Datei zu Kompilieren und somit,
ohne dass sie ins Repository aufgenommen wurde, verfügbar machen
oder eine Testumgebung starten, die etwa bei Pull Requests Semantische Konflikte
festellen kann [@silva2020].
Actions bestehen aus Jobs, die auf einer Virtuellen Maschiene ausgeführt werden.
Actions bestehen aus Jobs, die auf einer Virtuellen Maschine ausgeführt werden.
## Technische Voraussetzungen
Theoretisch gibt es keine Beschränkung welche Dateien Versioniert werden können,
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
......@@ -530,7 +534,7 @@ 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
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
......@@ -575,9 +579,9 @@ bringen.
Daher bringen viele Programmiersprachen Systeme zur Abhängigkeitsverwaltung
mit sich, diese Abhängigkeiten können in einer versionierten Datei hinterlegt
werden.
Eine universellere Lösung ist das anbieten von Kompilier beziehungsweise
Ausführungs Umgebungen als Docker Container,
die im Rahmen der Veranstaltung vorgestellt werden.
Eine universellere Lösung ist das anbieten von Kompilier- beziehungsweise
Ausführungsumgebungen als Docker Container,
die im Rahmen der Veranstaltung vorgestellt wird.
Git unterstützt zwar Digitale Signaturen, jedoch sind diese nicht zwingend
erforderlich, sodass Spoofing sehr einfach ist.
......@@ -637,7 +641,7 @@ dass SSH und der Private Schlüssel verwendet werden[^6].
so wird das Arbeitsverzeichnis verwendet.
`git clone [-o <Name>] <Repo> [<Verz.>]`
: Erzeugt eine Lokale kopie des entfernten Repository im angegeben
: Erzeugt eine Lokale Kopie des entfernten Repository im angegeben
Verzeichnis.
Ein remote wird unter dem angegeben Namen angelegt,
ohne Angabe des Namens wird *origin* verwendet.
......@@ -650,7 +654,7 @@ dass SSH und der Private Schlüssel verwendet werden[^6].
lassen sich auch nur Teile der Änderungen übernehmen.
`git commit [-m <Beschreibung>]`
: Erzeugt einen neuen commit, wobei der aktuelle Commit Vorgänger wird.
: Erzeugt einen neuen Commit, wobei der aktuelle Commit Vorgänger wird.
Die Spitze des aktuellen Zweiges zeigt danach auf den neuen Commit.
Wird die Beschreibung weggelassen, so öffnet sich ein Editor.
......@@ -667,7 +671,7 @@ dass SSH und der Private Schlüssel verwendet werden[^6].
`git merge [--no-ff] <Referenz>...`
: Führt merge der Referenzen, hauptsächlich Zweige, aus.
Die Option `--no-ff` Zwingt das erstellen eines merge Commits.
Die Option `--no-ff` Zwingt das erstellen eines Merge-Commits.
`git push <Remote> [<src>[:<dst>]]`
: Merge den durch `src` angegeben Zweig mit dem durch `dest` angegeben
......
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