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

write remotes section

parent 9cea89fe
Pipeline #142371 passed with stages
in 7 minutes and 52 seconds
......@@ -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
......
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