1. Einleitung
Was behandelt dieses Buch?
Typographische Konventionen
Weitere Informationen und Hilfe
2. Konzepte
Der Arbeitsbaum, der Index und Commits
Branches, Tags und Refs
Das Repository, Remote-Branches und Tracking-Branches
3. Installation
Binäre Installationspakete
Linux
OS X
Windows
Andere Betriebssysteme
Selbst kompilieren
Voraussetzungen
Das Kompilieren
Installieren der Hilfstexte und Manpages
Shell-Erweiterungen
Bash
Zsh
tcsh
4. Arbeiten mit Git
Neue Repositories erstellen
Ein vorhandenes Repository kopieren
Git konfigurieren
Grundkonfiguration
Hilfstexte deaktivieren
Dateien ignorieren
Dateiattribute
Versionierungsbefehle
Neue Dateien in das Repository aufnehmen
Änderungen im Dateisystem verwerfen
Änderungen aus dem Index entfernen
Commit
Änderungen einchecken
Den letzten Commit nachbearbeiten
Partielle Änderungen stagen
Interaktives Staging
Dateien verschieben und umbenennen
Dateien und Verzeichnisse löschen
Commits rückgängig machen
Revisionismus: Commit-History bearbeiten
Tags
Stashes
Stashes erstellen
Stashes anzeigen
Den Inhalt eines Stashes anzeigen
Änderungen aus einem Stash wiederherstellen
Stashes löschen
Informationsbefehle
Allgemeiner Status
Wer war das?
Wann war das?
Formatierung der Logausgaben
Ausgabe zeitlich einschränken
Andere Filter
Was hat sich zwischen zwei Commits geändert?
Was hat dieser Commit bewirkt?
Misc
Frühlingsdiät
Repository-Konsistenz prüfen
Lokale Branches
Grundlegende Branch-Verwaltung
Vorhandene Branches anzeigen
Branches erstellen
Umbenennen von vorhandenen Branches
Den aktuellen Branch wechseln
Dateien aus anderen Branches kopieren
Nur bestimmte Commits in den aktuellen Branch übernehmen
Branches löschen
Zusammenführen von Branches
Zusammenführen mit Merge
Konfliktbehebung
Zweigpunkte mit Rebase verschieben
Konfliktbehebung
Verteiltes Arbeiten
Aliase für Repositories
Tracking-Branches
Vorhandene Tracking-Branches anzeigen
Liste der Tracking-Branches abgleichen
Tracking-Branches aktualisieren
Branches anderer Repositories importieren
Eigene Branches und Änderungen in ein entferntes Repository exportieren
Submodule
Submodule anlegen
Submodule anzeigen
Submodule aktualisieren
Submodule löschen
Patches mithilfe von E-Mails verarbeiten
Erstellen von Patches
Versenden der Patches
Patches aus mbox-Dateien anwenden
Repositories veröffentlichen
Mit dem Git-Protokoll freigeben
Repositories mit HTTP veröffentlichen
Hooks
5. Tipps und Tricks
Merges rückgängig machen
Versehentlich gelöschte Branches wiederbeleben
Fehlersuche mit git bisect
Eigene Git-Aliase anlegen
CLI Merge-Graph
Netzwerkbefehle durch persistente SSH-Verbindungen beschleunigen
Push-Strategien
6. Ein Beispiel für ein Branching-Modell
Die Umgebung
Feature-Branches
Hotfixes
Tagging
7. GitHub
Git-Repositories
Organisationen und Teams
Vergleichen und Kommentieren
Forking und Pull Requests
Authentifizierung
Gist
Tipps und Tricks
Tastaturkürzel
Online editieren
Whitespace bei Diffs ignorieren
GitHub-Alternativen
8. Frontends
gitk
git gui
Instaweb
9. Git-Client und Subversion-Server
Am Anfang war der Klon
SVN-Properties und Ignore-Listen
Das Tagesgeschäft: Updaten, Branchen, Rebase/Merge, Commit
Konfliktmanagement
Merge-Konflikte
Rebase-Konflikte
Problemquellen und Ärgernisse
Whitespaces
Binäre Dateien
Branches
A. Vergleich von Git- und Subversion-Befehlen
B. Ausgabeparameter
Steuerung der Patch-Generierung
Statusausgaben
Filter
Ausgabeformatierung
Sonstige Parameter
C. Escape-Sequenzen der Logformatierung
D. Formate für Commit-Namen
E. Ausblick auf Git 2.0
git push
git add
git svn
Stichwortverzeichnis
Impressum
Dieses Buch entstand, nachdem der Autor sich nach jahrelanger Verwendung von Subversion mit dem distributierten Versionierungssystem Git angefreundet hatte. Es soll keine erschöpfende Git-Referenz darstellen (was im Taschenbuchformat auch gar nicht möglich wäre). Vielmehr wird das Material im Referenzkapitel nach Aufgabenbereichen organisiert und dann beschrieben, wie bestimmte, mehr oder weniger alltägliche Aufgaben mit Git bewältigt werden können.
In diesem Buch wird Git tendenziell aus der Perspektive desjenigen betrachtet, der vornehmlich Subversion als Versionierungssystem verwendet oder verwendet hat. Insbesondere Kapitel 9, ist an Migrationswillige gerichtet, die sich zunächst einmal kontrolliert mit Git anfreunden wollen, bevor der vollständige Wechsel vollzogen wird, und für diejenigen Anwender, denen ein Subversion-Server vorgegeben ist, die aber dennoch die Vorzüge von Git nicht missen möchten.
Das bedeutet aber nicht, dass das Buch nur für diese Zielgruppe interessant wäre. Der übrige Teil besteht in einer Referenz zu den Alltagsbefehlen und deren meistgenutzten Parametern. Die einzelnen Git-Befehle bringen aber in der Regel einen weitaus größeren Umfang an Optionen und Parametern mit, als in diesem Buch auch nur ansatzweise umrissen werden könnte. Außerdem sind viele Low-Level-Befehle verfügbar, auf die hier gar nicht eingegangen werden kann. Falls Ihnen eine bestimmte Möglichkeit fehlt, empfehle ich Ihnen, einen Blick in die Manpages der Git-Befehle zu werfen. In den meisten Fällen sollten Sie hier fündig werden.
Dennoch wird davon ausgegangen, dass Sie als Leser zumindest grundlegendes Wissen über die Unix-Umgebung und die Kommandozeile mitbringen und schon einmal mit einem Versionierungssystem gearbeitet haben.
Kursiv
Kennzeichnet Pfadnamen und Dateinamen (z. B. Programmnamen), Internet-Adressen (z. B. Domainnamen und URLs) sowie hervorgehobene oder neu definierte Begriffe.
Nichtproportionalschrift
Kennzeichnet Befehle und Optionen, die wörtlich eingegeben werden sollen.
Nichtproportionalschrift kursiv
Kennzeichnet Werte, die vom Benutzer in entsprechend angepasst eingegeben werden.
Nichtproportionalschrift fett
Wird verwendet, um Teile eines Programms oder einer Konfigurationsdatei hervorzuheben
Um Git herum ist ein mächtiges Ökosystem mit sehr vielen Ressourcen im Netz vorhanden. Zentrale Anlaufstelle ist natürlich die Homepage von Git im WWW: http://www.git-scm.com. Hier finden Sie nicht nur die aktuellen Versionen zum Herunterladen, sondern auch ein Wiki sowie Links auf umfangreiche Dokumentationen für die verschiedensten Zielgruppen und auf verwandte Projekte.
Eine Liste von grafischen Frontends und Tools finden Sie unter http://git.or.cz/gitwiki/InterfacesFrontendsAndTools.
Freunde von Screencasts werden bei http://git-scm.com/videos glücklich.
In diesem Kapitel werden die Grundkonzepte von Git in seiner Eigenschaft als verteiltes Versionsverwaltungssystem erörtert. Diese Konzepte sollten Sie kennen, wenn Sie die Arbeitsweise von Git im Detail verstehen wollen und den Grund kennen möchten, warum gerade eine bestimmte Vorgehensweise gewählt wird.
Ein Projekt spannt einen mehr oder weniger umfangreichen Verzeichnisbaum auf Ihrer Festplatte auf. Im zugehörigen Repository wird ein mehr oder minder großer Teil dieses Verzeichnisbaums verwaltet. Temporäre Dateien, Logdateien und andere transiente Daten werden üblicherweise aus der Verwaltung durch Git ausgeschlossen, obwohl sie Teil des Verzeichnisbaums des Projekts sind. Der von Git verwaltete Teil des Projekt-Verzeichnisbaums wird als Arbeitsbaum
bezeichnet.
Wenn Git Änderungen in das Repository einbringen soll, erstellt Git zunächst ein virtuelles Abbild des aktuellen Zustands des Arbeitsbaumes. Dieser Prozess wird staging
genannt, und das virtuelle Abbild ist in der Git-Nomenklatur der Index
. Dies ist in der Abbildung dargestellt.
Beim Speichern der Änderungen in das Repository erzeugt Git aus dem aktuellen Index-Inhalt einen Commit
und versieht diesen mit einer Revisionsnummer. Für die Nummerierung von Revisionen werden SHA1-Hashes verwendet, die aus dem Inhalt des Commits errechnet werden und aus 40 hexadezimalen Ziffern bestehen. Da Git auch mit einem eindeutigen Präfix der Revisionsnummer arbeiten kann, wird üblicherweise nur mit den ersten 7 Ziffern gearbeitet.
Hier sieht man auch schon einen wesentlichen Unterschied von Git zu traditionellen Revisionsverwaltungssystemen wie CVS oder Subversion: Ein Commit bezieht sich auf den gesamten Arbeitsbaum und nicht auf einzelne Dateien. Git garantiert damit jederzeit einen konsistenten Zustand im Arbeitsbaum.
Sofern die Revisionsnummer bekannt ist, besteht unter Git zwar ebenfalls die Möglichkeit, einzelne Dateien auf den Zustand einer bestimmten Version zu setzen. Allerdings fließt dies als Änderung in den Zustand des aktuellen Arbeitsbaums ein. Dieser Arbeitsschritt ist unter Git eher unüblich und sollte nur mit Bedacht und in Einzelfällen durchgeführt werden.
Bei einem Branch handelt es sich um eine Kette von Commits, bei der jeder Commit auf seinen – oder seine – Eltern-Commit(s) verweist. Branches sind auch untereinander verknüpft; von jedem Commit kann ein neuer Branch abgezweigt werden, auch von solchen Commits, die inzwischen durch andere Commits verborgen werden. Ebenso können unterschiedliche Branches wieder zusammengeführt werden. Der Haupt-Branch heißt traditionell master
, nimmt aber abgesehen von seinem Namen keinerlei Sonderstellung ein. Der jüngste Commit eines Branches wird HEAD
genannt.
Das Zusammenführen von mehreren Branches wird als merge
bezeichnet, und führt zur Erzeugung eines Merge-Commits im Repository. Ein Merge-Commit weist mehrere Eltern-Commits auf, die alle zueinander gleich gestellt sind. Beim Mergen agiert Git damit nach dem Prinzip »Merge die folgenden Commits, wobei der resultierende Commit Teil des aktuellen Branches werden soll« und nicht »Merge die folgenden Commits in den aktuellen Branch«. Der Unterschied ist subtil, wird aber deutlich, wenn ein Merge rückgängig gemacht werden soll (siehe „Merges rückgängig machen“ im Kapitel Kapitel 5.
Einzelne Commits können auch mit einem Namen versehen werden, damit auch künftig auf einfache Weise auf sie verwiesen werden kann. Dies wird als tagging
bezeichnet und die Markierung entsprechend als tag
.
Die Bezeichnung eines bestimmten Commits mittels seiner Revisionsnummer, des Tag-Namens, des Branch-Namens (was den HEAD
-Commit impliziert) oder eine der anderen Möglichkeiten, die in Anhang aufgeführt sind, wird in der Git-Sprache als Ref
bezeichnet.
Das Git-Repository besteht im Wesentlichen aus einer Menge von Branches, die in einem Verhältnis zueinander stehen.
Als verteiltes Versionierungssystem bietet Git die Möglichkeit, Branches zwischen Ihrem Repository und anderen, entfernten Repositories zu lesen, zu schreiben und über das Netzwerk Branches miteinander zu synchronisieren. Ein Branch aus einem anderen Repository wird remote branch
genannt.
Da Git als echtes dezentrales Versionierungssystem konzipiert wurde, ist die Topologie der Repositories untereinander nicht zwingend sternförmig aufgebaut; die Beziehungen der Repositories können einen beliebigen Graphen darstellen, wobei kein Repository auf technischer Ebene eine Sonderstellung im Hinblick auf andere Repositories einnimmt.
Aus diesem Grund muss Git den Zustand der entfernten Branches, mit denen Sie arbeiten wollen, lokal zwischenspeichern. Hierbei wird eine vollwertige, lokale Kopie des entfernten Branches angelegt, der die Grundlage für lokale Lese-, Schreib- und Synchronisierungsvorgänge darstellt. Dieser Cache des entfernten Branches wird als tracking branch
bezeichnet.
Abbildung 2.1 Repository mit Branches
In diesem Kapitel wird beschrieben, wie Sie Git auf Ihrem Rechner installieren. Wie bei den meisten Open Source-Produkten können Sie entweder ein binäres Paket installieren, wie es vermutlich auch von der von Ihnen verwendeten Linux-Distribution mitgeliefert wird, oder sich den Quellcode besorgen und ihn manuell kompilieren. Binärpakete sind natürlich bequem und schnell, allerdings sind sie mit einem Eigenkompilat immer auf dem aktuellsten Stand.
Die zentrale Git-Website befindet sich aktuell unter http://git-scm.com. Hier finden Sie nicht nur den Quellcode und Binärpakete für die unterschiedlichen Betriebssysteme und Distributionen, sondern auch Dokumentationen, aktuelle Neuigkeiten und ein Wiki, das Ihnen bei Problemen vielerlei Art sehr helfen kann.
Unter http://git-scm.com/download stehen binäre Installationspakete für OS X und Windows zur Verfügung.
Für Linux-Distributionen, FreeBSD, OpenBSD sowie Solaris finden sich hier die Installationsanleitungen, um das Git-Paket der jeweiligen Distribution zu installieren. Falls Ihr System hier nicht aufgeführt ist oder Sie mit der von Ihrer Distribution angebotenen Git-Version unzufrieden sind, können Sie auf die Kompilation und Installation aus dem Quelldateien ausweichen.
Der einfachste Weg besteht darin, das Git-Paket Ihrer verwendeten Linux Distribution zu installieren. Falls Sie unabhängig von Ihrer Distribution auf der Höhe der Zeit bleiben wollen, können Sie Git auch aus den Quell-Paketen heraus kompilieren und installieren.
Unter OS X stehen verschiedene Möglichkeiten zur Verfügung, Git zu installieren. Zum einen wird eine (meist etwas ältere) Git-Version mit Xcode ausgeliefert. Alternativ kann Git mittels Homebrew installiert und aktuell gehalten werden.
Die Installationsanleitung zu Homebrew findet man auf der entsprechenden Homepage: http://brew.sh.
Wenn Homebrew installiert ist, sollten zunächst die Paketdefinitionen mit
$ brew update
aktualisiert werden. Anschließend lässt sich Git ganz einfach mittels
$ brew install git
installieren. Mit
$ brew upgrade git
kann Git dann auf dem System aktuell gehalten werden.
Wenn Sie sowohl Xcode als auch Git über Homebrew installiert haben, sollten Sie darauf achten, dass bei PATH
der Installationspfad des Git aus Homebrew (/usr/local/git/bin) vor /usr/bin aufgeführt ist. Anderenfalls wird Git nur aus dem Xcode-Paket genutzt.
Unter Windows können Sie Git in zwei Varianten installieren: als Cygwin-Paket oder als natives msys-Paket.
Gehen wir zunächst auf das msys-Paket ein, da hier die Installation recht gradlinig verläuft: Laden Sie sich das Installationspaket herunter, führen Sie es aus und freuen Sie sich über Git unter Windows. Das war’s.
Um die Cygwin-Variante verwenden zu können, muss bereits die Cygwin-Umgebung installiert sein. Die können Sie unter http://www.cygwin.com beziehen. Unter Cygwin sollten Sie zusätzlich noch folgende Pakete installieren: openssh
aus dem Abschnitt Net
der Paketauswahl, aus dem Libs
-Abschnitt tcltk
sowie subversion-perl
und zusätzlich einen Editor, den Sie für Commit-Kommentare und Ähnliches verwenden wollen.
Wenn Sie Git auf einem hier nicht aufgeführten Betriebssystem verwenden möchten, ohne es selbst kompilieren zu müssen, besteht noch eine weitere Möglichkeit – sofern eine Java-Laufzeitumgebung für Ihr Betriebssystem vorhanden ist. In der Eclipse-IDE ist eine reine Java-Implementierung eines Git-Clients integriert.
Das Kompilieren von Hand ist bei Git nicht sonderlich aufwendig, sofern Sie nur die Software an sich installieren möchten. Um die Dokumentation aus dem Quellcodepaket mit zu erstellen, sind einige zusätzliche Handgriffe erforderlich.
Quellcodepakete können als .zip- oder .tar.gz-Datei von https://github.com/git/git/releases heruntergeladen werden. Wenn Sie Git bereits einsetzen, können Sie natürlich auch das Repository für Git klonen und hieraus komplieren. Zur Entstehungszeit dieses Buches findet sich das autoritative Repository für Git auf GitHub unter https://github.com/git/git.
Um Git erfolgreich zu kompilieren, sind folgende Bibliotheken und die entsprechenden Header-Dateien notwendig: zlib und SSH.
Perl 5.8 oder eine spätere Version wird ebenfalls empfohlen. Falls Sie nicht mit partiellen Commits arbeiten möchten oder mit SVN Repositories interagieren wollen, können Sie Perl beim Kompilieren umgehen, indem Sie beim make-Befehl den Parameter NO_PERL=YesPlease
mit angeben. Im Regelfall sollten Sie Perl als Abhängigkeit allerdings belassen.
Optional, aber empfohlen ist OpenSSL für den SHA1-Hashing-Algorithmus. Falls Ihnen OpenSSL nicht zur Verfügung steht, wird Git auch mit einer alternativen Bibliothek für das Hashing ausgeliefert. Unter MacOS X versucht Git ab der Version 1.8.3 mit CommonCrypto anstatt OpenSSL zu linken. Wenn CommonCrypto nicht zur Verfügung steht, fällt Git auf OpenSSL zurück.
Falls Sie mit HTTP Projekte verwalten möchten, benötigen Sie noch libcurl
und expat
. Wenn Ihnen das SSH- sowie das Git-native Protokoll genügen, sind diese Bibliotheken nicht erforderlich.
Für den Fall, dass Sie die grafischen Tools verwenden möchten, benötigen Sie noch das wish
-Paket für Tcl/TK.
Eine gettext
-Bibliothek ist für lokalisierte Git-Ausgaben erforderlich. Im Regelfall wird mit GNU’s libintl
gearbeitet, allerdings funktioniert auch die standardmäßige gettext
-Bibliothek von Solaris. Wenn Sie keine übersetzten Texte verwenden möchten, können Sie bei der Kompilation dem make-Befehl den Parameter NO_GETTEXT=YesPlease
übergeben. In diesem Fall wird Git lediglich englischsprachige Ausgaben bereitstellen.
Sofern Sie die Perforce-Konnektivität von Git verwenden möchten, sollten Sie Python 2.4 oder eine spätere Version bereitstellen. Python 3.x wird hier jedoch aktuell nicht unterstützt.
Wenn Sie die Hilfstexte und Dokumentation ebenfalls generieren und installieren möchten, muss AsciiDoc installiert sein. Beim Autor hat das zu einer Kaffeepause und der Installation von knapp 300 MByte an Abhängigkeiten geführt. Alternativ können Sie vorformatierte Hilfstexte separat herunterladen und installieren. Dies wird im Abschnitt zur Generierung der Hilfstexte in diesem Kapitel beschrieben (siehe „Installieren der Hilfstexte und Manpages“).
AsciiDoc baut auf DocBook auf. Es gibt Berichte darüber, dass die DocBook XSL-Definitionen der Version 1.72 und 1.73 fehlerhaft seien. Für 1.73 müssen Sie gegebenenfalls den mitgelieferten Patch contrib/patches/docbook-xsl-manpages-charmap.patch installieren.
Den Quellcode können Sie als traditionelles Archiv unter https://github.com/git/git/releases herunterladen und mit
$ tar xfzv git-X.Y.Z.tar.gz
bzw.
$ unzip git-X.Y.Z.zip
entpacken, wobei es sich bei X.Y.Z
um die Version des heruntergeladenen Git-Paketes handelt. Falls bei Ihrem Betriebssystem kein Gnu-Tar mitgeliefert wird, werden Sie wahrscheinlich das Paket zunächst explizit entpacken müssen:
$ gzip -c git-X.Y.Z.tar.gz | tar -xvf -
Alternativ können Sie die aktuellen Git-Quellen auch mit Git herunterladen, sofern Sie es bereits installiert haben:
$ git clone https://github.com/git/git.git
Wechseln Sie in das Verzeichnis mit dem gerade entpackten Git-Quellcode und führen Sie die Befehle
$ make $ make install
aus, um Git (zunächst ohne Dokumentation) mit den Standard-Konfigurationsoptionen zu installieren.
Da Git von Hause aus kein configure-Skript mehr zur Verfügung stellt, müssen Sie Zielverzeichnisse im Makefile direkt angeben. Suchen Sie hierzu nach prefix
und editieren Sie den nachfolgenden Abschnitt entsprechend Ihrer Bedürfnisse.
Um die Hilfstexte zu erzeugen und zu installieren, müssen Sie zusätzlich noch den folgenden Befehl ausführen:
$ make install-doc
Falls Sie lieber vorformatierte Hilfstexte installieren, können Sie die Texte für Ihre Git-Version unter http://code.google.com/p/git-core/downloads/list herunterladen. Die Pakete heißen git-htmldocs-X.Y.Z.tar.gz bzw. git-manpages-X.Y.Z.tar.gz.
Entpacken Sie das Archiv für die Manpages in einem man-Wurzelverzeichnis, das dem System bereits als Manpage-Baum bekannt ist, beispielsweise /usr/local/man:
$ cd /usr/local/man $ tar xfzv /pfad/zu/git-manpages-X.Y.Z.tar.gz
Aktualisieren Sie anschließend die Datenbank der installierten Manpages für Ihr System mit mandb
.
Die HTML-Dateien können Sie analog im Unterverzeichnis share/doc/git-doc unter Ihrem Git-Installationsverzeichnis entpacken. Allerdings müssen Sie Git mitteilen, dass Sie lieber die HTML-Hilfstexte nutzen, anderenfalls wird es versuchen, Ihnen die Manpages anzuzeigen:
$ git config --global help.format html $ git config --global help.browser /pfad/zu/ihrem/webbrowser
Nachdem Sie Git erfolgreich auf Ihrem System installiert haben, gilt es noch, ein paar globale Konfigurationsvariablen vor der ersten Verwendung zu belegen:
$ git config --global core.editor /usr/bin/vim # oder ein Editor # Ihrer Wahl $ git config --global user.name "Vorname Nachname" $ git config --global user.email ihre@email.adres.se
Ihre Commits werden von Git automatisch mit dem Namen und der E-Mail-Adresse versehen, die Sie hier angeben. Falls sie jeweils wissen möchten, welche Daten von Ihnen sich im Internet finden, sollten Sie sich eventuell eine separate E-Mail-Adresse für Git-Projekte zulegen.
Ab Git 1.8.4 werden Terminalausgaben von Git standardmäßig farbig ausgegeben. Wenn Sie dies deaktivieren möchten, nutzen Sie den folgenden Befehl:
$ git config --global color.ui false
Bei Git-Versionen vor 1.8.4 muss die farbige Terminal-Ausgabe manuell aktiviert werden:
$ git config --global color.ui auto
Im entpackten Quellcode-Verzeichnis von Git finden Sie unter contrib/completion eine Konfigurationsdatei für bash
, zsh
sowie der tcsh
, die die Tabulator-Vervollständigung von Git-Befehlen, Branch-Namen und Kommandozeilen-Parametern ermöglicht.
Sie können die Datei git-completion.bash systemweit über /etc/bash_completion oder für sich privat über ~/.bash_completion einbinden. Falls diese Dateien nicht zur Verfügung stehen, können Sie auf /etc/bash.bashrc bzw. ~/.bashrc zurückgreifen.
Kopieren Sie dazu die Konfigurationsdatei an eine öffentliche Stelle Ihres Systems und binden Sie sie ein:
. /pfad/zu/git-completion.bash # oder alternativ: source /pfad/zu/git-completion.bash
Viele aktuelle Bash-Installationen stellen ein Verzeichnis /etc/bash_completion.d bereit. In diesem Fall müssen Sie die Datei nur in dieses Verzeichnis zu kopieren, und beim nächsten Starten einer Shell stehen die Vervollständigungen dieser Shell zur Verfügung.
Ferner können Sie überlegen, Ihren Haupt-Shell-Prompt (PS1) so anzupassen, dass der aktuelle Branch-Name innerhalb von Projektverzeichnissen angezeigt wird, die mit Git arbeiten:
export PS1='\u@\h:\w$(__git_ps1 " (%s)")\$ '
führt zu einem Shell-Prompt, das wie folgt aussieht:
user@host:~/my_project (master)$
Dabei ist master
der aktuelle Branch-Name.
Das zsh
-Integrationsskript weist das Bash-Skript intern als Abhängigkeit auf. Sie können den Pfad zum Bash-Skript wie folgt setzen, sofern Sie es nicht nach /etc/bash_completion kopieren:
zstyle ':completion:*:*:git:*' script /pfad/zu/.git-completion.sh
Es wird empfohlen, das Zsh-Skript nach ~/.zsh/_git zu kopieren und mit der folgenden Zeile in Ihre .zshrc-Datei einzubinden:
fpath=(~/.zsh $fpath)
Das tcsh
-Skript setzt die tcsh
der Version 6.16.00 oder einer späteren Version voraus und nutzt intern das Bash-Skript.
Kopieren Sie die Dateien git-completion.bash nach ~/.git-completion.bash (dieser Pfadname ist obligatorisch und darf nicht geändert werden) sowie git-completion.tcsh nach ~/.git-completion.tcsh. Hiernach müssen Sie noch die folgende Zeile zu Ihrer .tcshrc hinzufügen:
source ~/.git-completion.tcsh
Falls Sie ähnlich wie bei der Bash Vorschläge zur Autovervollständigung wünschen, können Sie zusätzlich noch den folgenden Befehl zu Ihrer .tcshrc hinzufügen:
set autolist=ambiguous