write remotes section

paper/paper.md

@@ -401,7 +401,41 @@ wenn sie in einem eigen Kontext entwickelt werden.
 Der Wechsel zwischen Kontexten erfordert nur das Anpassen der Veränderten
 Dateien im Arbeitsverzeichnis.
 
-## TODO: Verteiltes Git
+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.
+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
+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.
+
+Um Änderungen an einen Remote zu senden, stellt Git die Push Operation bereit.
+Hier wird zunächst mit dem Remote ausgehandelt welchen Objekte hochgeladen
+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,
+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.
+
+Die Änderungen werden mit der Fetch Operation heruntergeladen, aber noch
+nicht mit dem lokalen Zweig zusammengeführt.
+Die Zweige des Remotes sind lokal unter seinem Namensraum verfügbar,
+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
+Merge Operation verbindet.
 
 ## TODO: Der Charakteristische GitHub Arbeitsablauf