-
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
10.5 Git Interna - Die Referenzspezifikation (engl. Refspec)
Die Referenzspezifikation (engl. Refspec)
In diesem Buch haben wir simple Zuordnungen von remote Branches zu lokalen Referenzen verwendet, diese können jedoch komplexer sein. Angenommen, Sie haben die letzten Abschnitte mitverfolgt und ein kleines lokales Git-Repository erstellt, und möchten nun eine remote hinzufügen:
$ git remote add origin https://github.com/schacon/simplegit-progit
Durch Ausführen des obigen Befehls wird ein Abschnitt zur .git/config
Datei Ihres Repositorys hinzugefügt. Es wird der Name des Remote-Repositorys (origin
), die URL des Remote-Repositorys und die refspec angegeben sind, die zum Abrufen verwendet werden soll:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
Das Format der Refspec ist zunächst ein optionales +
, gefolgt von <src>:<dst>
, wobei <src>
das Muster für Referenzen auf der Remote-Seite ist. <dst>
gibt an wo diese Referenzen lokal nachverfolgt werden.
Das +
weist Git an, die Referenz zu aktualisieren, auch wenn es sich nicht um einen fast-forward handelt.
In der Standardeinstellung, die automatisch von einem Befehl git remote add origin
geschrieben wird, ruft Git alle Referenzen unter refs/heads/
auf dem Server ab und schreibt sie lokal in refs/remotes/origin/
.
Wenn sich auf dem Server also ein master
Branch befindet, können Sie auf das Log dieses Branches lokal zugreifen, indem Sie eine der folgenden Aktionen ausführen:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
Sie sind alle gleichwertig, da Git sie zu refs/remotes/origin/master
erweitert.
Wenn Git stattdessen jedes Mal nur den master
Branch und nicht jeden anderen Branch auf dem Remote-Server pullen soll, können Sie die Abrufzeile so ändern, dass sie nur auf diesen Branch verweist:
fetch = +refs/heads/master:refs/remotes/origin/master
Dies ist nur die Standard Refspec für git fetch
für diesen Remote.
Wenn Sie einen einmaligen Abruf durchführen möchten, können Sie die spezifische Refspec auch in der Befehlszeile angeben.
Um den master
Branch auf dem Remote lokal nach origin/mymaster
zu pullen, können Sie Folgendes ausführen:
$ git fetch origin master:refs/remotes/origin/mymaster
Sie können auch mehrere Refspecs angeben. In der Befehlszeile können Sie mehrere Branches wie folgt pullen:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
In diesem Fall wurde der master
Branch pull abgelehnt, da er nicht als Fast-Forward aufgeführt war.
Sie können dies überschreiben, indem Sie das +
vor der Refspec angeben.
Sie können auch mehrere Refspecs zum Abrufen in Ihrer Konfigurationsdatei angeben.
Wenn Sie immer die Branches master
und experiment
vom origin
Remote abrufen möchten, fügen Sie zwei Zeilen hinzu:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Seit Git 2.6.0 können Sie partielle Globs in Pattern verwenden, um mehrere Branches anzupassen, dann funktioniert das hier:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Noch besser, Sie können Namespaces (oder Verzeichnisse) verwenden, um dasselbe mit mehr Struktur zu erreichen.
Wenn Sie ein QS-Team haben, das eine Reihe von Branches pusht, und Sie möchten nur den master
Branch und einen der Branches des QS-Teams erhalten, dann können Sie einen Konfigurationsabschnitt wie diesen verwenden:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Wenn Sie über einen komplexen Workflow-Prozess verfügen, bei dem QS-Team und Entwickler Branches pushen und Integrationsteams auf Remotebranches pushen bzw. daran zusammenarbeiten, können Sie sie auf diese Weise problemlos mit Namespaces versehen.
Pushende Refspecs
Es ist schön, dass Sie auf diese Weise Referenzen mit Namespaces abrufen können, aber wie bringt das QS-Team seine Branches überhaupt an die erste Stelle eines Namespace qa/
?
Sie erreichen dies, indem Sie Refspecs zum Pushen verwenden.
Wenn das QS-Team seinen master
Branch auf qa/master
auf dem Remote-Server verschieben möchte, kann folgendes ausgeführt werden:
$ git push origin master:refs/heads/qa/master
Wenn Git dies bei jedem Start von git push origin
automatisch ausführen soll, können sie ihrer Konfigurationsdatei einen push
Wert hinzufügen:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
Dies wird wiederum dazu führen, dass ein git push origin
den lokalen master
Branch standardmäßig zum remote qa/master
Branch pusht.
Anmerkung
|
Sie können die Refspec nicht zum Abrufen von einem Repository und zum Verschieben auf ein anderes Repository verwenden. Ein Beispiel wie das geht finden Sie unter Ihr öffentliches GitHub-Repository aktuell halten. |
Löschende Referenzen
Sie können mit Refspec auch Verweise vom Remote-Server löschen, indem Sie Folgendes ausführen:
$ git push origin :topic
Die Syntax der Refspezifikation lautet <src>:<dst>
. Das Weglassen des <src>
Teils bedeutet, im Grunde genommen, dass der topic
Branch auf dem Remote leer bleibt, wodurch er gelöscht wird.
Oder Sie können die neuere Syntax verwenden (verfügbar seit Git v1.7.0):
$ git push origin --delete topic