git config

In diesem Dokument sehen wir uns den Befehl git config im Detail an. Wir haben die Nutzung von git config auf unserer Seite Einrichten eines Repositorys kurz angesprochen. Der Befehl git config ist eine praktische Funktion, die zum Einrichten von Git-Konfigurationswerten auf globaler oder auch lokaler Projektebene verwendet wird. Diese Konfigurationsebenen entsprechen den .gitconfig-Textdateien. Die Ausführung von git config modifiziert die Konfigurationstextdatei. Wir werden auf gebräuchliche Konfigurationseinstellungen wie E-Mail, Benutzername und Editor eingehen. Außerdem sprechen wir über Git-Aliasse, die die Einrichtung von Kurzformen für häufig genutzte Git-Vorgänge ermöglichen. Wenn du dich mit git config und den verschiedenen Git-Konfigurationseinstellungen vertraut machst, wird dir dies bei der Erstellung eines leistungsstarken, benutzerdefinierten Git-Workflows helfen.

Anwendung

Der einfachste Anwendungsfall von git config ist das Aufrufen eines Konfigurationsnamens, um den definierten Wert für diesen Namen anzuzeigen. Konfigurationsnamen sind durch Punkte abgetrennte Strings, die je nach Hierarchie aus einem "Abschnitt" und einem "Schlüssel" bestehen. Ein Beispiel: user.email

 git config user.email

In diesem Beispiel ist "email" eine untergeordnete Eigenschaft des Benutzerkonfigurationsblocks. Sofern diese konfiguriert ist, wird damit eine E-Mail-Adresse zurückgegeben, die Git den lokal erstellten Commits zuordnet.

Git-Konfigurationsebenen und -dateien

Bevor wir auf die Anwendung von git config eingehen, sollten wir uns zunächst mit Konfigurationsebenen befassen. Du kannst den Befehl git config mit Argumenten ergänzen, um festzulegen, auf welcher Konfigurationsebene er ausgeführt wird. Folgende Konfigurationsebenen können angegeben werden:

  • --local

Wenn keine Konfigurationsoption festgelegt wurde, erfolgen Schreibvorgänge mit git config standardmäßig auf lokaler Ebene. Die lokale Konfiguration wird auf das Repository angewendet, in dessen Kontext der Befehl git config ausgeführt wird. Die lokalen Konfigurationswerte werden in einer Datei im .git-Verzeichnis des Repositorys gespeichert: .git/config

  • --global

Die Konfiguration auf globaler Ebene ist benutzerspezifisch, das heißt, sie wird auf einen Benutzer des Betriebssystems angewendet. Die globalen Konfigurationswerte werden in einer Datei im Stammverzeichnis des Benutzers gespeichert: ~ /.gitconfig bei Unix-Systemen und C:\Users\\.gitconfig unter Windows.

  • --system

Die Konfiguration auf Systemebene wird auf der gesamten Maschine angewendet. Das umfasst alle Benutzer eines Betriebssystems und alle Repositorys. Die Datei für die Konfiguration auf Systemebene liegt in einer gitconfig-Datei außerhalb des System-Root-Pfads. $(prefix)/etc/gitconfig bei Unix-Systemen. Unter Windows XP findest du diese Datei im Pfad C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Git\config und unter Windows Vista und neueren Versionen unter C:\ProgramData\Git\config.

Die Priorität der Konfigurationsebenen lautet: lokale Ebene, globale Ebene, Systemebene. Auf der Suche nach Konfigurationswerten setzt Git also an der lokalen Ebene an und arbeitet sich zur Systemebene hoch.

Einen Wert schreiben

Aufbauend auf unserem Wissen über git config sehen wir uns nun ein Beispiel an, bei dem ein Wert eingegeben wird:

 git config --global user.email "your_email@example.com"

In diesem Beispiel wird der Wert your_email@example.com für den Konfigurationsnamen user.email definiert. Mit dem Flag --global wird dieser Wert für den aktuellen Benutzer des Betriebssystems festgelegt.

Git-Konfigurationseditor: core.editor

Bei vielen Git-Befehlen öffnet sich zur weiteren Eingabe ein Texteditor. Am häufigsten wird git config zur Konfiguration des Editors in Git verwendet. Im Folgenden werden beliebte Editoren und die entsprechenden git config-Befehle aufgelistet:

Editor config-Befehl
Atom ~ git config --global core.editor "atom --wait"~
emacs ~ git config --global core.editor "emacs"~
nano ~ git config --global core.editor "nano -w"~
vim ~ git config --global core.editor "vim"~
Sublime Text (Mac) ~ git config --global core.editor "subl -n -w"~
Sublime Text (Win, 32-Bit-Installation) ~ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublimetext.exe' -w"~
Sublime Text (Win, 64-Bit-Installation) ~ git config --global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"~
Textmate ~ git config --global core.editor "mate -w"~

Merge-Tools

Git startet im Falle eines Merge-Konflikts ein "Merge-Tool". Standardmäßig nutzt Git dabei eine interne Implementierung eines gängigen Unix-Diff-Programms. Die interne Git-Diff-Anzeige zeigt nur eine Minimalansicht der Merge-Konflikte. Alternativ kannst du eine der vielen Merge-Konfliktlösungen von Drittanbietern verwenden. Einen Überblick über die zahlreichen Merge-Tools und die Konfiguration erhältst du in unserem Leitfaden mit Tipps und Tools für Merge-Konflikte in Git.

git config --global merge.tool kdiff3

Farbiger Output

Git unterstützt einen farbigen Terminal-Output zum schnellen Lesen des Git-Outputs. Du kannst deinen Git-Output anpassen, um ein personalisiertes Farbschema zu verwenden. Diese Farbwerte werden mit dem Befehl git config festgelegt.

color.ui

Das ist die Master-Variable für die Git-Farben. Wenn du sie auf "false" setzt, wird sämtlicher farbiger Terminal-Output in Git deaktiviert.

 $ git config --global color.ui false

Standardmäßig ist color.ui auf "automatisch" gesetzt und zeigt den unmittelbaren Terminal-Output farbig an. Bei der Umleitung des Outputs zu einer Datei oder einem anderen Prozess wird der Code bei der automatischen Einstellung nicht farbig ausgegeben.

Du kannst den Wert color.ui auf "always" setzen, um auch bei der Umleitung zu Dateien oder Pipes eine farbige Codeausgabe zu erhalten. Dies kann jedoch zu unvorhergesehenen Problemen führen, wenn die Pipe, die die Daten erhält, keinen farbkodierten Input erwartet.

Git-Farbwerte

Neben color.ui gibt es noch weitere genauere Farbeinstellungen. Wie auch color.ui können all diese Farbeinstellungen auf "false", "auto" oder "always" gesetzt werden. Außerdem kannst du einen bestimmten Farbwert für sie festlegen. Hier sind ein paar Beispiele für unterstützte Farbwerte:

  • normal
  • black
  • red
  • green
  • yellow
  • blue
  • magenta
  • cyan
  • white

Farben können auch mit hexadezimalen Farbcodes, wie etwa #ff0000 oder ANSI-256-Farbwerten angegeben werden, falls dein Terminal diese unterstützt.

Einstellungen zur Farbkonfiguration in Git

1. color.branch

  • Konfiguriert die Farbe, in der der Git-Branch-Befehl ausgegeben wird

2. color.branch.>

  • Dieser Wert ist auch auf den Git-Branch-Output anwendbar. Für den <slot> kannst du Folgendes einsetzen:
    • 1. current: der aktuelle Branch
    • 2. local: ein lokaler Branch
    • 3. remote: ein Remote-Branch-Ref in Refs/Remotes
    • 4. upstream: ein Upstream-Tracking-Branch
    • 5. plain: ein beliebiger anderer Ref

3. color.diff

  • Zeigt Output bei git diff, git log und git show in Farbe

4. color.diff.<slot>

  • Wenn du einen Wert für <slot> unter color.diff konfigurierst, weiß Git, auf welches Stück Text welche Farbe angewendet werden soll.
    • 1. context: der Diff-Kontext-Text. Als Git-Kontext versteht man die Textzeilen in einem Diff oder Patch, in denen Änderungen hervorgehoben werden.
    • 2. plain: ein anderer Ausdruck für "context"
    • 3. meta: zeigt Output der Diff-Metadaten in Farbe
    • 4. frag: zeigt Output der "Hunk-Kopfzeile" oder der "Funktion in der Hunk-Kopfzeile" in Farbe
    • 5. old: zeigt Output der entfernten Zeilen im Diff in Farbe
    • 6. new: zeigt die hinzugefügten Diff-Zeilen in Farbe an
    • 7. commit: zeigt Commit-Header innerhalb des Diffs in Farbe an
    • 8. whitespace: legt farbige Markierung von Leerzeichenfehlern in einer Diff fest

5. color.decorate.>

  • Passt die Farbe für den Output git log --decorate an. Für den <slot> werden folgende Werte unterstützt: branch, remoteBranch, tag, stash oder HEAD. Sie sind jeweils auf lokale Branches, Remote-Tracking-Branches, Tags, gestashte Änderungen und den HEAD anwendbar.

6. color.grep

  • Gestaltet git grep-Output farbig.

7. color.grep.>

  • Gilt auch für git grep. Die Variable <slot> legt fest, welcher Teil der grep-Ausgabe eingefärbt werden soll.
    • 1. context: nicht zusammengehöriger Text in Kontextzeilen
    • 2. filename: Präfix des Dateinamens
    • 3. function: Zeilen mit Funktionsnamen
    • 4. linenumber: Präfix der Zeilennummer
    • 5. match: übereinstimmender Text
    • 6. matchContext: zusammengehöriger Text in Kontextzeilen
    • 7. matchSelected: zusammengehöriger Text in ausgewählten Zeilen
    • 8. selected: nicht zusammengehöriger Text in ausgewählten Zeilen
    • 9. separator: Trennzeichen zwischen Feldern in einer Zeile (:, - und =) und zwischen Hunks (--)

8. color.interactive

  • Mit dieser Variable werden interaktive Anweisungen und Output farblich dargestellt. Beispiele dafür sind git add --interactive und git clean --interactive.

9. color.interactive.

  • Die Variable kann so festgelegt werden, dass sie auf spezifischeren "interaktiven Output" abzielt. Als Werte für <slot> sind verfügbar: prompt, header, help, error; jeder davon reagiert auf den entsprechenden interaktiven Output.

10. color.pager

  • Aktiviert oder deaktiviert farbigen Output bei Verwendung des Pagers

11. color.showBranch

  • Aktiviert oder deaktiviert farbigen Output für den Befehl "git show branch"

12. color.status

  • Ein Boolescher Wert, der den farbigen Output für "git status" aktiviert oder deaktiviert

13. color.status.<slot>

Dient zum Festlegen individueller Farben für bestimmte "git status"-Elemente. <slot> unterstützt folgende Werte:

  • 1. header
    • betrifft den Kopfzeilentext des Statusbereichs
  • 2. added or updated
    • beide betreffen Dateien, die hinzugefügt, aber nicht committet werden
  • 3. changed
    • betrifft geänderte Dateien, die dem Git-Index noch nicht hinzugefügt wurden
  • 4. untracked
    • nimmt Dateien ins Visier, die von Git nicht verfolgt werden
  • 5. branch
    • stellt den aktuellen Branch in Farbe dar
  • 6. nobranch
    • die Farbe, in der die Warnung "Kein Branch" dargestellt wird
  • 7. unmerged
    • hebt Dateien mit nicht gemergten Änderungen farbig hervor

Aliasse

Vielleicht kennst du Aliasse bereits aus den Befehlszeilen deines Betriebssystems. Aliasse sind benutzerdefinierte Kurzformen, mit denen längere Befehle oder eine Kombination aus Befehlen verkürzt werden. Mit Aliassen sparst du dir Zeit und Aufwand bei der Eingabe von häufig verwendeten Befehlen. Git verfügt über ein eigenes System von Aliassen. Git-Aliasse werden oft zum Verkürzen von Commit-Befehlen gebraucht. Git-Aliasse werden in Git-Konfigurationsdateien gespeichert. Du kannst also mit dem Befehl git config Aliasse konfigurieren.

 git config --global alias.ci commit

Bei diesem Beispiel wird ein "ci"-Alias für den Befehl git commit erstellt. Danach kannst du git commit aufrufen, indem du git ci ausführst. Aliasse können sich auch auf andere Aliasse beziehen und starke Kombinationen bilden.

 git config --global alias.amend ci --amend

In diesem Beispiel wird eine Alias-Ergänzung vorgenommen, wobei der Alias "ci" mit dem Flag --amend zu einem neuen Alias zusammengesetzt wird.

Formatierung und Leerräume

Git bietet zahlreiche Features, um Probleme mit Leerräumen anzuzeigen, die bei der Verwendung von "git diff" entstanden sind. Probleme mit Leerräumen werden in der mit color.diff.whitespace konfigurierten Farbe hervorgehoben.

Folgende Features sind standardmäßig aktiviert:

  • blank-at-eol hebt verwaiste Leerräume am Zeilenende hervor
  • space-before-tab hebt ein Leerzeichen hervor, das vor einem Tabulatorzeichen steht, wenn damit eine Zeile eingerückt wird.
  • blank-at-eof hebt die Leerzeilen am Ende einer Datei hervor

Folgende Funktionen sind standardmäßig deaktiviert:

  • indent-with-non-tab hebt eine Zeile hervor, die mit Leerzeichen statt Tabstoppzeichen eingerückt ist
  • tab-in-indent hebt die erste Tab-Einrückung als Fehler hervor
  • trailing-space ist die Kurzform der Kombination von blank-at-eol und blank-at-eof
  • cr-at-eol hebt einen Zeilenumbruch am Zeilenende hervor
  • tabwidth= definiert, wie viele Zeichenpositionen ein Tabulatorzeichen belegt. Der Standardwert ist 8. Zulässig sind die Werte 1 bis 63

Zusammenfassung

In diesem Artikel haben wir die Verwendung des Befehls git config besprochen. Wir haben erläutert, warum der Befehl eine geeignete Methode zum Bearbeiten von nicht formatierten git config-Dateien ist. Außerdem haben wir uns grundlegende Lese- und Schreibvorgänge für Konfigurationsoptionen angesehen und gängige Konfigurationsmuster betrachtet:

  • Konfiguration des Git-Editors
  • Überschreiben von Konfigurationsebenen
  • Zurücksetzen von Standardkonfigurationen
  • Anpassen der Git-Farbanzeige

Insgesamt betrachtet ist git config ein Hilfsmittel, mit dem sich nicht formatierte git config-Dateien auf Festplatten schneller bearbeiten lassen. Wir haben die Optionen zur Personalisierung ausführlich behandelt. Zum Einrichten eines Repositorys sind Grundkenntnisse der Git-Konfigurationsoptionen erforderlich. Wesentliche Informationen dazu findest du in unserem Leitfaden.

Möchtest du Git kennenlernen?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen