08-vcs4.adoc

Versionsverwaltung 4

../overlay.adoc

Remotes

Einführung Remotes

GIT

Stupid Content Tracker, effizienter Objekt-Speicher mit der Fähigkeit zwei Objektspeicher miteinander zu Synchronisieren.

Einführung Remotes

Synchronsation bei Daten == Replikation

---

Synchronistion der Git-Objekte == Replikation aller Git-Objekte

Remotes

• Das letzte verbliebene Element in der Liste der Git-Objekte

• Ein lokales Repository kann mit vielen verschiedenen entfernten Repositories verbunden sein

• wenn Repo durch git clone entstanden ist, gibt es genau ein Remote mit dem Namen origin

## Zeigt alle konfigurierten Remotes an
$ git remote -v
origin   https://github.com/barclay-reg/dhbw-slides.git (fetch)
origin   https://github.com/barclay-reg/dhbw-slides.git (push)

Branches Synchronisieren

• Sync bei GIT-Objekten relativ einfach

• Sync bei Referenzen etwas komplexer

  • Problem: Referenz wurde auf beiden Seiten verändert

  • Lösung:

    • Speichern aller lokalen und remote Referenzen

    • Speichern der Verbindung zwischen lokaler und remote Referenz

Remote Referenzen

## Auflistung aller Dateien im Ordner .git/refs
$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/heads/master
.git/refs/heads/my-branch-1
.git/refs/tags
.git/refs/tags/test-tag-0
.git/refs/tags/test-tag-1
.git/refs/remotes
.git/refs/remotes/origin
.git/refs/remotes/origin/master
.git/refs/remotes/origin/other-branch-2

Note	unter refs/remotes wird der Stand eines Branch-Zeigers auf Remote abgelegt diese Zeiger können lokal nicht verändert werden Branch my-branch-1 existiert nur bei mir loka Brnach other-branch-2 existiert nur bei origin

Remote Tracking Branches

• Wenn ein lokaler Branch mit einem remote Branch verbunden ist, dann spricht man von einem sog.:

  • Remote-Tracking-Branch

  • oder Upstream-Branch

  • Git weiss, dass der lokale Branch dem remote Branch folgt

  • z.B. der Branch origin/master wird von master getracked

• Name der remote Branches == Namen des Remote Repository plus dem Namen des Branches zusammen

  • z.B. origin/feature-1

Note	Dies sind die Vorraussetzungen, damit Git eine Synchronisierung durchführen kann

Remote Tracking Branches

Kommandos

## Zeigt alle Remote Branches an
$ git branch –r
origin/master
origin/feature-1
## Legt neuen Branch an, der origin/feature-1 trackt
$ git branch feature-1 origin/feature-1
## Shortcut, legt automatisch lokalen Branch an, falls ein
## Branch `origin/feature-1` existiert
$ git checkout feature-1
## Definiert für den aktuellen lokalen Branch den
## Namen des Remote Branches
$ git branch --set-upstream-to origin/neues-feature

Arbeiten mit Remotes

Transportwege

Fetch und Pull

• git fetch

  • Holt alle Commits von den remote Repository(ies)

  • keine Änderung an der Workcopy

  • oft ist danach ein Merge notwendig (3WM oder FF)

• git pull

  • Shortcut für git fetch & git merge

## ohne die Angabe von `origin` werden alle Remotes abgefragt
$ git fetch origin
## merge des Remote-Branches auf den aktuellen lokalen Branch
$ git merge origin/master
## Shortcut für die beiden oberen Befehle
## auch hier kann `origin` weggelassen werden
$ git pull origin

Fetch und Pull

Fetch und Pull

Note	Alle commits der beiden Remote Branches wurden übertragen. Auch die Branchzeiger wurden übertragen, aber der Tracking-Branch (master) wurde nicht verändert - nun ist sichtbar, dass dieser von orign/master abweicht (diverged) - die Lösung dafür ist entweder ein 3WM oder ein Rebase+FF-Merge

Push

• git push

  • überträgt alle lokalen Commits zu dem Remote Repository

  • Nur erlaubt, wenn (remote) ein Fast-Forward-Merge möglich ist, ansonsten vorher git pull

  • danach ist KEIN Ändern der Historie/Commits empfohlen

    • Kein Commit-Amend, Reset von Branches, Rebasing

  • je nach Konfiguration wird nur der lokale Branch oder alle Branches synchronisiert

    • config: push.default=simple

Push

Push

Note	Alle commits des lokalen Branches wurden übertragen - nur für den aktiven Branch.

Clone & Fork

• git clone

  • Kopieren eines remote Repositories auf den eigenen Rechner

  • "erste Synchronisieren" plus "Checkout"

  • kein git init mehr nötig

• fork

  • kein Git Befehl

  • Findet auf einem Git-Server statt, z.B. auf https://github.com

  • im Hintergrund wird auch git clone ausgeführt

Clone & Fork

• Problem: Wie kommen Änderungen des Originals zu meinem Fork?

• Lösung: Original als weiteres Remote-Repo anlegen

Ohne Fork

Ohne Fork - Anders

Ohne Fork - Remotes

$ git remote -v
origin   github.com/fn-tfe15-2-g1/dhbw-painground.git (fetch)
origin   github.com/fn-tfe15-2-g1/dhbw-painground.git (push)

Mit Fork

Mit Fork - Anders

Mit Fork - Remotes

$ git remote add upstream https://github.com/barclay-reg/dhbw-painground.git
$ git remote -v
origin   github.com/fn-tfe15-2-g1/dhbw-painground.git (fetch)
origin   github.com/fn-tfe15-2-g1/dhbw-painground.git (push)
upstream   github.com/barclay-reg/dhbw-painground.git (fetch)
upstream   github.com/barclay-reg/dhbw-painground.git (push)

Mit Fork - Änderungen abholen

## Änderungen von Remote "upstream" holen
$ git fetch upstream
## auf eigenen Branch "master" wechseln
$ git checkout master
## Alle commits von Branch "master" von Remote "upstream"
## in aktuellen Branch mergen
$ git merge upstream/master
## Änderungen an github senden
$ git push

Pull Request

• Antrag, ein oder mehrere Commits von einem Branch in einen anderen Branch zu mergen

  • sinnvoll von einem Fork zum Original

  • auch sinnvoll "innerhalb" eines einzigen Repos

• kann jemandem zugewiesen werden

• Erlaubt Code-Review, Code-Diskussion

• wenn Antrag akzeptiert ist, wird ein Pull (fetch & merge) gemacht

• Kann per git request-pull gestartet werden, aber

• besser per Web-Interface (Github, Bitbucket, Gitlab)

Wieso PR

• Warum nicht einfach Mergen?

  • (Feature)-Branches bestehen manchmal länger

    • Niemand außer dem Author weiß, wann das Feature fertig ist

    • Erstellen des PR ist ein eindeutiger Trigger für

      • Start des Code-Reviews

      • Start von (langwierigen) automatisierten Tests

Wieso PR

• PR im Umfeld von Original & Fork sind extrem hilfreich

  • Maintainer des Originals erlaubt nur wenigen das direkte Committen (und vor allem das Pushen) in das eigene Repo

  • mit Forks kann jeder Freiwillige trotzdem an dem Code arbeiten

  • mit dem Annehmen des PR erlaubt der Maintainer, die "fremden" Commits in sein Repo aufzunehmen