-
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 Ihre 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 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 Ihre 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, müssen Sie wissen, wie Sie Remote-Repositorys verwalten können. Remote-Repositorys sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. Sie können mehrere einrichten, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar für Sie ist. Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn Sie Ihre Arbeit teilen möchten. 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 Ihrem lokalen Rechner liegen.
Es ist durchaus möglich, dass Sie mit einem „entfernten“ Repository arbeiten können, das sich tatsächlich auf demselben Host befindet auf dem Sie gerade arbeiten. 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 Sie konfiguriert haben, können Sie den Befehl git remote
aufrufen.
Er listet die Kurznamen der einzelnen von Ihnen festgelegten Remote-Handles auf.
Wenn Sie Ihr Repository geklont haben, sollten Sie zumindest origin
sehen – das ist der Standardname, den Git dem Server gibt, von dem Sie geklont haben:
$ 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
Sie können zusätzlich auch -v
angeben, das Ihnen 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 Sie mehr als einen Remote haben, 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.
Beachten Sie, dass diese Remotes eine Vielzahl von Protokollen verwenden; wir werden mehr darüber erfahren, wenn wir 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
für Sie hinzufügt.
Im Folgendem beschreiben wir, wie Sie einen neuen Remote hinzufügen können.
Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das Sie leicht verweisen können, führen Sie 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 können Sie die Zeichenfolge pb
auf der Kommandozeile anstelle der gesamten URL verwenden.
Wenn Sie beispielsweise alle Informationen fetchen möchten, die Paul hat, die aber noch nicht in Ihrem Repository enthalten sind, können Sie 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 – Sie können ihn in eine Ihrer Branches einbinden oder an dieser Stelle in einen lokalen Branch wechseln (engl. checkout), wenn Sie ihn inspizieren möchten.
Wir werden in Git Branching detailliert beschreiben, was Branches sind und wie man sie nutzt.
Fetchen und Pullen von Ihren Remotes
Wie Sie gerade gesehen haben, können Sie Daten aus Ihren Remote-Projekten abrufen:
$ git fetch <remote>
Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt, die Sie noch nicht haben. Danach sollten Sie Referenzen auf alle Branches von diesem Remote haben, die Sie jederzeit einbinden oder inspizieren können.
Wenn Sie ein Repository klonen, 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 Ihr lokales Repository herunterlädt – er merged sie nicht automatisch mit Ihrer Arbeit zusammen oder ändert das, woran Sie gerade arbeiten.
Sie müssen das Ganze manuell mit Ihrer Arbeit zusammenführen, wenn Sie fertig sind.
Wenn Ihr aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), können Sie den Befehl git pull
verwenden, um diesen entfernten Branch automatisch zu holen und dann mit Ihrem aktuellen Branch zusammenzuführen (siehe den nächsten Abschnitt und Git Branching für weitere Informationen).
Das könnte ein einfacherer oder komfortablerer Workflow für Sie sein. Standardmäßig richtet der Befehl git clone
Ihren 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 Sie ihn geklont haben.
Wenn Sie git pull
ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben. Anschliessend wird automatisch versucht diese Daten in ihren Code zu mergen.
Anmerkung
|
Ab der Version 2.27 von Git wird Falls Sie das Standardverhalten (möglichst ein fast-forward, ansonsten einen Merge-Commit erstellen) von Git beibehalten wollen:
Wenn Sie mit dem Pullen einen Rebase machen wollen:
|
Zu Ihren Remotes Pushen
Wenn Sie Ihr Projekt an einem Punkt haben, den Sie teilen möchten, können Sie es zum Upstream verschieben (engl. pushen).
Der Befehl dafür lautet: git push <remote> <branch>
.
Wenn Sie Ihren master
Branch auf Ihren origin
Server verschieben möchten (Zur Erinnerung: das Klonen richtet im Regelfall diese beiden Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen:
$ git push origin master
Dieser Befehl funktioniert allerdings nur, wenn Sie von einem Server geklont haben, auf den Sie Schreibzugriff haben und wenn in der Zwischenzeit noch niemand anderes gepusht hat. Wenn Sie und ein anderer Benutzer gleichzeitig klonen und Sie beide Upstream pushen wollen, Sie aber etwas später nach Upstream pushen, dann wird Ihr Push zu Recht abgelehnt. Sie müssen zuerst dessen Bearbeitung abholen und in Ihre einbinden, bevor Sie pushen können. Siehe Kapitel 3 Git Branching mit ausführlicheren Details zum Pushen auf Remote-Server.
Inspizieren eines Remotes
Wenn Sie mehr Informationen über einen bestimmten Remote sehen möchten, können Sie den Befehl git remote show <remote>
verwenden.
Wenn Sie diesen Befehl mit einem remote Kurznamen ausführen, wie z.B. origin
, erhalten Sie 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 Ihnen mit, dass, wenn Sie sich im Master-Zweig befinden und git pull
ausführen, 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 Sie möglicherweise treffen werden.
Wenn Sie Git hingegen intensiver verwenden, können 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 Zweig automatisch gepusht wird, wenn Sie git push
ausführen, während Sie sich in bestimmten Branches befinden.
Er zeigt Ihnen auch, welche entfernten Branches auf dem Server vorhanden sind, die Sie noch nicht haben, welche entfernten Branches Sie haben, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit Ihrem Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn Sie git pull
ausführen.
Umbenennen und Entfernen von Remotes
Sie können git remote rename
ausführen, um den Kurznamen eines Remotes zu ändern.
Wenn Sie beispielsweise pb
in paul
umbenennen möchten, können Sie dieses mit dem Befehl git remote rename
machen:
$ git remote rename pb paul
$ git remote
origin
paul
Es ist zu beachten, dass dadurch auch alle Ihre Remote-Tracking-Branchnamen geändert werden.
Was vorher unter pb/master
referenziert wurde, ist jetzt unter paul/master
zu finden.
Wenn Sie einen Remote aus irgendwelchen Gründen entfernen möchten – Sie haben den Server verschoben oder verwenden einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann können Sie entweder git remote remove
oder git remote rm
verwenden:
$ git remote remove paul
$ git remote
origin
Sobald Sie die Referenz auf einen Remote auf diese Weise gelöscht haben, werden auch alle mit diesem Remote verbundenen Remote-Tracking-Branches und Konfigurationseinstellungen gelöscht.