-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Deine Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere VCS-Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in deine Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
2.5 Git Grundlagen - Mit Remotes arbeiten
Mit Remotes arbeiten
Um an Git-Projekte mitarbeiten zu können, musst du wissen, wie du deine Remote-Repositorys verwalten kannst. Remote-Repositorys sind Versionen deines Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. Du kannst Mehrere davon haben, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar ist. Die Zusammenarbeit mit Anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn du deine Arbeit teilen möchtest. Die Verwaltung von Remote-Repositorys umfasst das Wissen, wie man entfernte Repositorys hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr. In diesem Abschnitt werden wir einige dieser Remote-Management-Fertigkeiten erörtern.
Anmerkung
|
Remote-Repositorys können auch auf deinem lokalen Rechner liegen.
Es ist durchaus möglich, dass du mit einem „entfernten“ Repository arbeiten kannst, das sich eigentlich auf demselben Host befindet auf dem du gerade arbeitest. Das Wort „remote“ bedeutet nicht unbedingt, dass sich das Repository an einem anderen Ort im Netzwerk oder Internet befindet, sondern nur, dass es an einem anderen Ort liegt. Die Arbeit mit einem solchen entfernten Repository würde immer noch alle üblichen Push-, Pull- und Fetch-Operationen einschließen, wie bei jedem anderen Remote-Repository. |
Auflisten der Remotes
Um zu sehen, welche Remote-Server bei dir konfiguriert sind, kannst du den Befehl git remote
aufrufen.
Er listet die Kurznamen der einzelnen von dir festgelegten Remote-Handles auf.
Wenn du dein Repository geklont hast, solltest du zumindest origin
sehen – das ist der Standardname, den Git dem Server gibt, von dem du geklont hast:
$ git clone https://github.com/schacon/ticgit
Cloning into 'ticgit'...
remote: Reusing existing pack: 1857, done.
remote: Total 1857 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
Resolving deltas: 100% (772/772), done.
Checking connectivity... done.
$ cd ticgit
$ git remote
origin
Du kannst zusätzlich auch -v
angeben, das dir die URLs anzeigt, die Git für den Kurznamen gespeichert hat, um beim Lesen und Schreiben auf diesen Remote zuzugreifen:
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
Wenn du mehr als einen Remote hast, listet der Befehl sie alle auf. Ein Repository mit mehreren Remotes für die Arbeit mit mehreren Beteiligten könnte beispielsweise so aussehen.
$ cd grit
$ git remote -v
bakkdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
cho45 https://github.com/cho45/grit (fetch)
cho45 https://github.com/cho45/grit (push)
defunkt https://github.com/defunkt/grit (fetch)
defunkt https://github.com/defunkt/grit (push)
koke git://github.com/koke/grit.git (fetch)
koke git://github.com/koke/grit.git (push)
origin git@github.com:mojombo/grit.git (fetch)
origin git@github.com:mojombo/grit.git (push)
Das bedeutet, dass wir Beiträge von jedem dieser Benutzer ziemlich einfach abrufen können. Möglicherweise haben wir zusätzlich die Erlaubnis, auf einen oder mehrere von diesen zu pushen, obwohl wir das hier nicht erkennen können.
Beachte: Diese Remotes verwenden unterschiedliche Protokollen; wir werden mehr darüber hier erfahren: Git auf einem Server installieren.
Hinzufügen von Remote-Repositorys
Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl git clone
stillschweigend den Remote origin
hinzufügt.
Im Folgendem beschreiben wir, wie du einen neuen Remote hinzufügen kannst.
Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das du verweisen kannst, führe git remote add <shortname> <url>
aus:
$ git remote
origin
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)
Nun kannst du die Zeichenfolge pb
auf der Kommandozeile anstelle der gesamten URL verwenden.
Wenn du beispielsweise alle Informationen fetchen möchtest, die Paul hat, die aber noch nicht in deinem Repository enthalten sind, kannst du git fetch pb
ausführen:
$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
* [new branch] master -> pb/master
* [new branch] ticgit -> pb/ticgit
Pauls master
Branch ist nun lokal als pb/master
erreichbar – Du kannst ihn in eine deiner Branches mergen oder ihn in einen lokalen Branch auschecken, wenn du ihn inspizieren möchten.
Wir werden in Git Branching detailliert beschreiben, was Branches sind und wie man sie nutzt.
Fetchen und Pullen deiner Remotes
Wie du gerade gesehen hast, kannst du Daten aus deinem Remote-Projekt abrufen:
$ git fetch <remote>
Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt, die du noch nicht hast. Danach solltest du Referenzen auf alle Branches dieses Remote haben, die du jederzeit mergen oder inspizieren kannst.
Wenn du ein Repository klonst, fügt der Befehl dieses entfernte Repository automatisch unter dem Namen „origin“ hinzu.
So holt git fetch origin
alle Änderungen, die seit dem Klonen (oder dem letzten Abholen) auf diesen Server abgelegt (engl. pushed) wurden.
Es ist jedoch wichtig zu beachten, dass der Befehl git fetch
nur die Daten in dein lokales Repository herunterlädt – er merged sie nicht automatisch mit deiner Arbeit zusammen oder ändert das, woran du gerade arbeitest.
Du musst das Ganze manuell mit deiner Arbeit zusammenführen, wenn du soweit bist.
Wenn dein aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), kannst du den Befehl git pull
verwenden, um diesen entfernten Branch automatisch zu fetchen und dann mit deinem aktuellen Branch zu mergen (siehe den nächsten Abschnitt und Git Branching für weitere Informationen).
Das könnte ein einfacherer oder komfortablerer Workflow sein. Standardmäßig richtet der Befehl git clone
deinen lokalen master
Branch automatisch so ein, dass er den entfernten master
Branch (oder wie auch immer der Standard-Branch genannt wird) auf dem Server versioniert von dem du geklont hast.
Wenn du git pull
ausführst, werden normalerweise Daten von dem Server abgerufen, von dem du ursprünglich geklont hast. Anschliessend wird automatisch versucht diese Daten in deinem Code zu mergen.
Anmerkung
|
Ab der Version 2.27 von Git wird Falls du das Standardverhalten (möglichst ein fast-forward, ansonsten einen Merge-Commit erstellen) von Git beibehalten willst:
Wenn du jedoch mit dem Pullen einen Rebase machen willst:
|
Zu deinen Remotes Pushen
Wenn du dein Projekt an einem Punkt hast, an dem du es teilen möchtest, können wir es zum Upstream verschieben (engl. pushen).
Der Befehl dafür lautet: git push <remote> <branch>
.
Wenn du deinen master
Branch auf den origin
Server pushen möchtest (Zur Erinnerung: das Klonen richtet im Regelfall diese beiden Branches automatisch ein), dann kannst du diesen Befehl auch nutzen, um alle Commits, die du durchgeführt hast, auf den Server zu pushen:
$ git push origin master
Dieser Befehl funktioniert allerdings nur, wenn du von einem Server geklont hast, auf den du Schreibzugriff hast und wenn in der Zwischenzeit noch niemand anderes gepusht hat. Wenn du und ein anderer Benutzer gleichzeitig klonen und beide Upstream pushen wollen, du aber etwas später nach Upstream pushst, dann wird dein Push zu Recht abgelehnt. Du musst zuerst dessen Bearbeitung abholen und in deine einbinden, bevor du pushen kannst. Siehe Kapitel 3 Git Branching mit ausführlicheren Details zum Pushen auf Remote-Server.
Inspizieren eines Remotes
Wenn du mehr Informationen über einen bestimmten Remote sehen möchten, kannst du den Befehl git remote show <remote>
verwenden.
Wenn du diesen Befehl mit einem remote Kurznamen ausführen, wie z.B. origin
, erhältst du bspw. folgende Meldung:
$ git remote show origin
* remote origin
Fetch URL: https://github.com/schacon/ticgit
Push URL: https://github.com/schacon/ticgit
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branches auf.
Der Befehl teilt dir mit: Wenn du dich im Master-Branch befindest und git pull
ausführst, der master
Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird.
Er listet auch alle Remote-Referenzen auf, die er abgerufen hat.
Das ist nur ein einfaches Beispiel, auf das du möglicherweise treffen wirst.
Wenn du Git hingegen intensiver verwendest, könnte die git remote show
Ausgabe wesentlich umfangreicher sein:
$ git remote show origin
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
markdown-strip tracked
issue-43 new (next fetch will store in remotes/origin)
issue-45 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
dev-branch pushes to dev-branch (up to date)
markdown-strip pushes to markdown-strip (up to date)
master pushes to master (up to date)
Dieser Befehl zeigt an, zu welchem Branch automatisch gepusht wird, wenn du git push
ausführst, während du dich in bestimmten Branches befindest.
Er zeigt dir auch, welche entfernten Branches auf dem Server vorhanden sind, die du noch nicht hast, welche entfernten Branches du hast, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit deinen Remote-Tracking-Branch zusammengeführt (gemerged) werden können, wenn du git pull
ausführst.
Umbenennen und Entfernen von Remotes
Du kannst git remote rename
ausführen, um den Kurznamen eines Remotes zu ändern.
Wenn du beispielsweise pb
in paul
umbenennen möchtest, kannst du dies mit dem Befehl git remote rename
erreichen:
$ git remote rename pb paul
$ git remote
origin
paul
Es ist zu beachten, dass dadurch auch alle deine Remote-Tracking-Branchnamen geändert werden.
Was vorher unter pb/master
referenziert wurde, ist jetzt unter paul/master
zu finden.
Wenn du einen Remote aus irgendwelchen Gründen entfernen möchten – Du hast den Server verschoben oder verwendest einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann kannst du entweder git remote remove
oder git remote rm
verwenden:
$ git remote remove paul
$ git remote
origin
Sobald du die Referenz auf einen Remote auf diese Weise gelöscht hast, werden auch alle mit diesem Remote verbundenen Remote-Tracking-Branches und Konfigurationseinstellungen gelöscht.