Git

git-config last updated in 2.47.1

NAME

git-config – Repository eigene oder globale Optionen auslesen und setzen

ÜBERSICHT

git config [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <name> [<value> [<value-pattern>]]
git config [<file-option>] [--type=<type>] --add <name> <value>
git config [<file-option>] [--type=<type>] [--fixed-value] --replace-all <name> <value> [<value-pattern>]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <name> [<value-pattern>]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <name> [<value-pattern>]
git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <name-regex> [<value-pattern>]
git config [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch <name> <URL>
git config [<file-option>] [--fixed-value] --unset <name> [<value-pattern>]
git config [<file-option>] [--fixed-value] --unset-all <name> [<value-pattern>]
git config [<file-option>] --rename-section <old-name> <new-name>
git config [<file-option>] --remove-section <name>
git config [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
git config [<file-option>] --get-color <name> [<default>]
git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]
git config [<file-option>] -e | --edit

BESCHREIBUNG

Sie können mit diesem Befehl Optionen abfragen/setzen/ersetzen/leeren. Der Name ist tatsächlich der Abschnitt und der Schlüssel, getrennt durch einen Punkt, und der Wert wird außer Acht gelassen.

Multiple lines can be added to an option by using the --add option. If you want to update or unset an option which can occur on multiple lines, a value-pattern (which is an extended regular expression, unless the --fixed-value option is given) needs to be given. Only the existing values that match the pattern are updated or unset. If you want to handle the lines that do not match the pattern, just prepend a single exclamation mark in front (see also BEISPIELE), but note that this only works when the --fixed-value option is not in use.

Die Option --type=<Typ> veranlasst git config zu überprüfen, ob ein- und ausgehende Werte unter den angegebenen <Typ> zulässig sind. Wenn kein --type=<Typ> angegeben ist, wird keine Kanonisierung durchgeführt. Benutzer können einen bestehenden --type Bezeichner mit --no-type aufheben.

Standardmäßig werden die Werte aus den lokalen Konfigurationsdateien des Systems, der globalen Einstellung und der des Repositorys ausgelesen. Die Optionen --system, --global, --local, ---worktree und --file <Datei-Name> können verwendet werden, um dem Befehl anzuweisen, nur von diesem Speicherort zu lesen (siehe den Abschnitt [DATEIEN]).

Beim Schreiben wird der neue Wert standardmäßig in die lokale Konfigurationsdatei des Repositorys geschrieben, und die Optionen --system, --global, --worktree, --file <filename> können benutzt werden, um dem Befehl mitzuteilen, dass er dorthin schreiben soll (Sie können --local angeben, aber das ist schon die Voreinstellung).

Dieser Befehl schlägt bei einem Fehler mit einem Nicht-Null-Status fehl. Einige dieser Exit-Codes sind:

Der Abschnitt oder Schlüssel ist ungültig (ret=1),
weder Abschnitt noch Name wurde angegeben (ret=2),
die Konfigurationsdatei ist falsch (ret=3),
die Konfigurationsdatei kann nicht geschrieben werden (ret=4),
Sie versuchen, eine nicht existierende Option aufzuheben (ret=5),
Sie versuchen, eine Option rückgängig zu machen/einzustellen, für die mehrere Zeilen übereinstimmen (ret=5), oder
Sie versuchen, einen ungültigen regulären Ausdruck (regexp) zu verwenden (ret=6).

Bei erfolgreichem Abschluss gibt der Befehl den Exit-Code 0 zurück.

A list of all available configuration variables can be obtained using the git help --config command.

OPTIONEN

--replace-all

Default behavior is to replace at most one line. This replaces all lines matching the key (and optionally the value-pattern).

--add

Adds a new line to the option without altering any existing values. This is the same as providing ^$ as the value-pattern in --replace-all.

--get

Liefert den Wert für einen angegebenen Schlüssel (optional gefiltert durch einen dem Wert entsprechenden Regex). Gibt Fehlercode 1 zurück, wenn der Schlüssel nicht gefunden wurde. Wenn mehrere Schlüsselwerte gefunden werden, wird der letzte Wert zurückgegeben.

--get-all

Entspricht --get, liefert aber alle Werte eines mehrwertigen Schlüssels zurück.

--get-regexp

Wie --get-all, interpretiert den Namen aber als regulären Ausdruck und gibt die Schlüsselnamen aus. Der Abgleich mit regulären Ausdrücken unterscheidet derzeit zwischen Groß- und Kleinschreibung und erfolgt gegen eine kanonisierte Version des Schlüssels, in der die Namen von Abschnitt und Variablen kleingeschrieben werden, die Namen von Unterabschnitten jedoch nicht.

--get-urlmatch <name> <URL>

When given a two-part name section.key, the value for section.<URL>.key whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for section.key is used as a fallback). When given just the section as name, do so for all the keys in the section and list them. Returns error code 1 if no value is found.

--global

Bei Schreib-Optionen: schreibt in die globale ~/.gitconfig Datei anstatt in die .git/config des Repositorys, schreibt in die $XDG_CONFIG_HOME/git/config Datei, wenn diese Datei existiert und die ~/.gitconfig Datei nicht.

Bei Lese-Optionen: Liest nur aus der globalen ~/.gitconfig und aus $XDG_CONFIG_HOME/git/config, statt aus allen verfügbaren Dateien.

Siehe auch [DATEIEN].

--system

Bei Schreib-Optionen: schreibt in die systemweite $(prefix)/etc/gitconfig Datei, anstatt im Repository auf .git/config.

Bei Lese-Optionen: nur aus systemweitem $(prefix)/etc/gitconfig lesen, nicht aus allen verfügbaren Dateien.

Siehe auch [DATEIEN].

--local

Bei Schreib-Optionen: Schreibt in die .git/config Datei des Repositorys. Dies entspricht dem Standardverhalten.

Bei Lese-Optionen: nur aus der Repository .git/config lesen, nicht aus allen verfügbaren Dateien.

Siehe auch [DATEIEN].

--worktree

Similar to --local except that $GIT_DIR/config.worktree is read from or written to if extensions.worktreeConfig is enabled. If not it’s the same as --local. Note that $GIT_DIR is equal to $GIT_COMMON_DIR for the main working tree, but is of the form $GIT_DIR/worktrees/<id>/ for other working trees. See git-worktree[1] to learn how to enable extensions.worktreeConfig.

-f <config-file>

--file <config-file>

For writing options: write to the specified file rather than the repository .git/config.

For reading options: read only from the specified file rather than from all available files.

Siehe auch [DATEIEN].

--blob <blob>

Analog zu --file, aber benutzt den genannten Blob anstelle einer Datei. Sie können z.B. master:.gitmodules verwenden, um Werte aus der Datei .gitmodules im Master-Branch zu lesen. Siehe den Abschnitt "REVISIONEN SPEZIFIZIEREN" in gitrevisions[7] für eine umfassende Liste von Schreibweisen für Blob-Namen.

--remove-section

Entfernt den angegebenen Abschnitt aus der Konfigurations-Datei.

--rename-section

Umbenennen des betreffenden Abschnitts auf einen neuen Namen.

--unset

Löscht die Zeile, auf die der Schlüssel passt, aus der Konfigurations-Datei.

--unset-all

Löscht alle Zeilen, auf die der Schlüssel passt, aus der Konfigurations-Datei.

-l

--list

Listet alle in der Konfigurations-Datei gesetzten Variablen mit ihren Werten auf.

--fixed-value

When used with the value-pattern argument, treat value-pattern as an exact string instead of a regular expression. This will restrict the name/value pairs that are matched to only those where the value is exactly equal to the value-pattern.

--type <Typ>

git config sorgt dafür, dass jede Eingabe oder Ausgabe unter der/den angegebenen Typ-Bedingung(en) gültig ist und wird ausgehende Werte in der zulässigen Form von `<Typ>`ausgeben.

Zulässige Werte von <Typ> enthalten:

bool: die Werte entweder als „wahr“ (true) oder „falsch“ (false) deklarieren.
int: die Werte als einfache Dezimalzahlen deklarieren. Ein optionales Suffix von k, m oder g bewirkt, dass der Wert der Eingabe mit 1024, 1048576 oder 1073741824 multipliziert wird.
bool-or-int: entsprechend der obigen Beschreibung entweder nach bool oder int kanonisieren.
path: kanonisieren durch Hinzufügen einer führenden ~ zum Wert von $HOME und ~user zum Home-Verzeichnis für den angegebenen Benutzer. Dieser Spezifizierer hat keine Auswirkung, wenn ein Wert gesetzt wird (aber Sie können git config section.variable ~/ von der Kommandozeile aus benutzen, um Ihre Shell die Erweiterung durchführen zu lassen)
expiry-date: kanonisieren durch Konvertieren von einem fixen oder relativen Datumsstring in einen Zeitstempel. Diese Angabe hat keine Auswirkung beim Setzen des Wertes.
color: Wenn Sie einen Wert erhalten, kanonisieren Sie ihn, indem Sie ihn in eine ANSI-Farb-Escape-Sequenz konvertieren. Wenn ein Wert festgelegt wurde, so wird eine Überprüfung durchgeführt, um sicherzustellen, dass der angegebene Wert als ANSI-Farbe kanonisierbar ist, aber er wird so wie er ist ausgegeben.

--bool

--int

--bool-or-int

--path

--expiry-date

Historische Optionen zur Auswahl eines Typ-Bezeichners. Stattdessen sollte man besser --type wählen (siehe oben).

--no-type

Setzt den zuvor eingestellten Typ-Bezeichner zurück, falls zuvor einer eingestellt war. Diese Option verlangt, dass git config die abgerufene Variable nicht kanonisiert. --no-type hat keine Wirkung ohne --type=<type> oder --<type>.

-z

--null

Für alle Optionen, die Werte und/oder Schlüssel ausgeben, immer die Werte mit einem Null-Zeichen beenden (anstatt eines Zeilenumbruchs). Stattdessen sollte ein Zeilenumbruch als Trennzeichen zwischen Schlüssel und Wert verwendet werden. Dies ermöglicht z.B. ein sicheres Parsen der Ausgabe, ohne durch in den Werten enthaltene Zeilenumbrüche verwirrt zu werden.

--name-only

Nur die Namen der Konfigurationsvariablen für --list oder --get-regexp ausgeben.

--show-origin

Die Ausgabe aller abgefragten Konfigurationsoptionen mit dem Origin-Typ (Datei, Standardeingabe, Blob, Kommandozeile) und dem aktuellen Original (Konfigurationsdateipfad, Ref oder Blob-ID, falls zutreffend) erweitern.

--show-scope

Similar to --show-origin in that it augments the output of all queried config options with the scope of that value (worktree, local, global, system, command).

--get-colorbool <name> [<stdout-is-tty>]

Find the color setting for <name> (e.g. color.diff) and output "true" or "false". <stdout-is-tty> should be either "true" or "false", and is taken into account when configuration says "auto". If <stdout-is-tty> is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise. When the color setting for name is undefined, the command uses color.ui as fallback.

--get-color <name> [<default>]

Findet für name die konfigurierte Farbe (z.B. color.diff.new) und gibt sie als ANSI-Farb-Escape-Sequenz für die Standardausgabe aus. Der optionale Parameter default wird stattdessen verwendet, wenn für name keine Farbe konfiguriert ist.

--type=color [--default=<Vorgabe>] wird gegenüber --get-color bevorzugt (bitte aber beachten, dass --get-color den durch --type=color angehängten Zeilenumbruch auslässt).

-e

--edit

Öffnet einen Editor, um die angegebene Konfigurationsdatei zu ändern; entweder aus --system, --global, oder dem Repository (die Voreinstellung).

--[no-]includes

Berücksichtigt include.* Direktiven in Konfigurationsdateien, wenn Werte nachgeschlagen werden. Standardeinstellung ist off, wenn eine bestimmte Datei angegeben wird (z.B. mit --file, --global, usw.) und on, wenn alle Konfigurationsdateien durchsucht werden.

--default <Wert>

Wird mit --get benutzt. Wenn die angeforderte Variable nicht gefunden wird, dann wird <Wert> so eingesetzt als ob dieser der Variablen zugewiesen wurde.

KONFIGURATION

pager.config wird nur bei der Auflistung der Konfiguration beachtet, d.h. bei der Verwendung von --list oder einem der --get-*, die mehrere Ergebnisse liefern können. Die Voreinstellung ist die Verwendung eines Pagers.

DATEIEN

Wenn nicht explizit mit --file verändert, gibt es vier Dateien, in welchen git-config nach Optionen sucht:

$(prefix)/etc/gitconfig: Systemweite Konfigurationsdatei.
$XDG_CONFIG_HOME/git/config: Zweite benutzerspezifische Konfigurationsdatei. Wenn $XDG_CONFIG_HOME nicht gesetzt oder leer ist, wird $HOME/.config/git/config verwendet. Jede einwertige Variable, die in dieser Datei gesetzt ist, wird mit dem überschrieben, was in ~/.gitconfig steht. Es empfiehlt sich, diese Datei nicht zu erstellen, wenn manchmal ältere Versionen von Git verwendet werden, da diese Datei erst seit relativ kurzer Zeit unterstützt wird.
~/.gitconfig: Benutzerspezifische Konfigurationsdatei. Auch „globale“ Konfigurationsdatei genannt.
$GIT_DIR/config: Spezifische Konfigurationsdatei für das Repository.
$GIT_DIR/config.worktree: Diese Angabe ist optional und wird nur durchsucht, wenn extensions.worktreeConfig in $GIT_DIR/config vorhanden ist.

Falls keine weiteren Optionen gegeben sind, werden alle Leseoperationen auf allen verfügbaren Dateien ausgeführt. Wenn die globale oder die systemweite Konfigurationsdateien fehlen, werden sie ignoriert. Falls die Konfigurationsdatei des Repositorys nicht verfügbar oder lesbar ist, wird git config mit einem Fehlercode, der nicht null ist, beendet. In beiden Fällen jedoch wird keine Fehlermeldung ausgegeben.

Die Dateien werden in der oben angegebenen Reihenfolge gelesen, wobei der zuletzt gefundene Wert Vorrang vor früher gelesenen Werten hat. Werden mehrere Werte ermittelt, dann kommen alle Werte eines Schlüssels aus allen Dateien zum Einsatz.

Einzelne Konfigurationsparameter können beim Ausführen eines git-Befehls mit der Option -c überschrieben werden. Siehe git[1] für weitere Details.

Alle Schreiboptionen schreiben standardmäßig in die Konfigurationsdatei des Repositorys. Beachten Sie, dass dies auch Optionen wie --replace-all und --unset betrifft. git config wird immer nur eine Datei zur gleichen Zeit ändern.

You can override these rules using the --global, --system, --local, --worktree, and --file command-line options; see OPTIONEN above.

ENVIRONMENT

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Take the configuration from the given files instead from global or system-level configuration. See git[1] for details.
GIT_CONFIG_NOSYSTEM: Legt fest, ob die Leseeinstellungen aus der systemweiten Datei $(prefix)/etc/gitconfig übersprungen werden sollen. Siehe git[1] für Einzelheiten.

Siehe auch [DATEIEN].

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>: If GIT_CONFIG_COUNT is set to a positive number, all environment pairs GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be added to the process’s runtime configuration. The config pairs are zero-indexed. Any missing key or value is treated as an error. An empty GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no pairs are processed. These environment variables will override values in configuration files, but will be overridden by any explicit options passed via git -c.

This is useful for cases where you want to spawn multiple git commands with a common configuration but cannot depend on a configuration file, for example when writing scripts.
GIT_CONFIG: If no --file option is provided to git config, use the file given by GIT_CONFIG as if it were provided via --file. This variable has no effect on other Git commands, and is mostly for historical compatibility; there is generally no reason to use it instead of the --file option.

BEISPIELE

Angenommen wird folgende .git/config-Datei:

#
# Dies ist die Konfigurationsdatei und
# ein '#' oder ein ';' stellt einen
# Kommentar dar.
#

; Kernvariablen
[core]
	; den Dateimodi nicht vertrauen
	filemode = false

; Unser diff-Algorithmus
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

; Proxyeinstellungen
[core]
	gitproxy="proxy-Befehl" für kernel.org
	gitproxy=default-proxy ; für den Rest

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
	cookieFile = /tmp/cookie.txt

Sie können den Dateimodus auf "true" setzen mit

% git config core.filemode true

Die hypothetischen Proxy-Befehlseinträge haben tatsächlich ein entsprechendes Anhängsel, um zu erkennen, auf welche URL sie sich beziehen. Hier erfahren Sie, wie Sie den Eintrag für kernel.org in "ssh" ändern können.

% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'

Dies stellt sicher, dass nur das Schlüssel/Wertpaar für kernel.org ersetzt wird.

Um den Eintrag für Umbenennungen zu löschen, verwenden Sie

% git config --unset diff.renames

Falls Sie einen Eintrag für eine Multivar (Eine Variable mit mehreren Einträgen, wie core.gitproxy oben), löschen möchten, müssen Sie eine Regex für den Wert exakt einer Zeile angeben.

Um den Wert für einen gegebenen Schlüssel abzufragen, benutzen Sie

% git config --get core.filemode

oder

% git config core.filemode

oder, um eine Multivar abzufragen:

% git config --get core.gitproxy "for kernel.org$"

Falls Sie alle Werte einer Multivar wissen möchten, verwenden Sie:

% git config --get-all core.gitproxy

Wenn Sie gerne gefährlich leben, können Sie alle core.gitproxy-Einträge durch einem neuen ersetzen mit

% git config --replace-all core.gitproxy ssh

Wenn Sie jedoch wirklich nur eine Zeile für den Standardproxy verändern möchten, beispielsweise diejenige ohne ein Anhängsel "for …", können Sie dies so tun:

% git config core.gitproxy ssh '! for '

Um tatsächlich nur Werte mit einem Ausrufezeichen abzugleichen, müssen Sie

% git config section.key value '[!]'

Um einen neuen Proxy hinzuzufügen, ohne einen der vorhandenen Proxys zu ändern, verwenden Sie

% git config --add core.gitproxy '"proxy-command" for example.com'

Ein Beispiel, um angepasste Farbe der Konfigurationsdatei in Ihrem Script zu verwenden:

#!/bin/sh
WS=$(git config --get-color color.diff.whitespace "blue reverse")
RESET=$(git config --get-color "" "reset")
echo "${WS}Ihre Leerzeichen-Farbe oder invertiertes Blau${RESET}"

Für URLs in https://weak.example.com wird http.sslVerify auf false gesetzt, während es für alle anderen auf true gesetzt wird:

% git config --type=bool --get-urlmatch http.sslverify https://good.example.com
true
% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com
false
% git config --get-urlmatch http https://weak.example.com
http.cookieFile /tmp/cookie.txt
http.sslverify false

KONFIGURATIONSDATEI

Die Git-Konfigurationsdatei enthält eine Reihe von Variablen, die das Verhalten der Git-Befehle beeinflussen. Die Dateien .git/config und optional config.worktree (siehe den Abschnitt „KONFIGURATIONSDATEI“ in git-worktree[1]) in jedem Repository werden verwendet, um die Konfiguration für dieses Repository zu speichern. Mit $HOME/.gitconfig wird außerdem pro Benutzer eine Konfiguration als Fallback-Werte für die Datei .git/config gespeichert. Die Datei /etc/gitconfig kann verwendet werden, um eine systemweite Standardkonfiguration zu sichern.

Die Konfigurationsvariablen werden sowohl von den "Plumbing"- als auch von den "Porcelain"-Befehlen verwendet. Die Variablen sind in Gruppen unterteilt, wobei der vollqualifizierte Variablenname das Segment nach dem letzten Punkt ist und der Gruppenname alles vor dem letzten Punkt. Die Variablennamen unterscheiden nicht zwischen Groß- und Kleinschreibung, erlauben nur alphanumerische Zeichen und - und müssen mit einem alphanumerischen Zeichen beginnen. Einige Variablen dürfen mehrmals vorkommen; wir sagen dann, die Variable ist mehrwertig.

Syntax

Die Syntax ist ziemlich flexibel und tolerant; Leerzeichen werden größtenteils ignoriert. Die Zeichen # und ; beginnen Kommentare bis zum Zeilenende, Leerzeilen werden ignoriert.

Die Datei besteht aus Gruppen und Variablen. Eine Gruppe beginnt mit dem Gruppennamen in eckigen Klammern und geht bis zum nächsten Gruppenanfang. Gruppennamen unterscheiden keine Groß- und Kleinschreibung. Nur alphanumerische Zeichen, - und . sind in Gruppennamen erlaubt. Jede Variable muss zu einer Gruppe gehören, was bedeutet, dass eine Gruppenüberschrift vor der ersten Variablenzuweisung zwingend ist.

Gruppen können weiter in Untergruppen unterteilt werden. Um eine Untergruppe zu beginnen, schreiben Sie ihren Namen in doppelten Anführungszeichen, durch ein Leerzeichen vom Gruppentitel getrennt, wie in folgendem Beispiel:

	[Gruppe "Untergruppe"]

Subsection names are case sensitive and can contain any characters except newline and the null byte. Doublequote " and backslash can be included by escaping them as \" and \\, respectively. Backslashes preceding other characters are dropped when reading; for example, \t is read as t and \0 is read as 0. Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don’t need to.

Es gibt außerdem die veraltete [Gruppe.Untergruppe]-Syntax. Mit dieser Syntax wird der Untergruppenname in Kleinbuchstaben konvertiert und unterscheidet dann auch zwischen Groß- und Kleinschreibung. Diese Untergruppennamen folgen den gleichen Einschränkungen wie Gruppennamen.

Alle anderen Zeilen (und der Rest der Zeile nach der Gruppenüberschrift) werden als Einstellungsvariablen erkannt, in der Form Name = Wert (oder nur Name, was bedeutet, der Wert der Variable ist "true"). Die Variablennamen unterscheiden zwischen Groß- und Kleinschreibung, dürfen nur alphanumerische Zeichen und - enthalten und müssen mit einem alphanumerischen Zeichen beginnen.

A line that defines a value can be continued to the next line by ending it with a \; the backslash and the end-of-line are stripped. Leading whitespaces after name =, the remainder of the line after the first comment character # or ;, and trailing whitespaces of the line are discarded unless they are enclosed in double quotes. Internal whitespaces within the value are retained verbatim.

Zwischen doppelten Anführungszeichen müssen doppelte Anführungszeichen " und Rückwärtsschrägstriche \ escaped werden: \" für " und \\ für \.

Die folgenden Escape-Sequenzen (neben \" und \\) werden erkannt: \n als Zeilenumbruch (NL), \t für Tab (HT, TAB) und \b für Backspace (BS). Andere Escape-Sequenzen (auch oktale Escape-Sequenzen) sind ungültig.

Includes (Dateieinbettungen)

Die Abschnitte include und includeIf erlauben es Ihnen, Konfigurationsanweisungen aus einer anderen Quelle einzubinden. Diese Abschnitte verhalten sich identisch zueinander mit der Ausnahme, dass die Abschnitte includeIf ignoriert werden können, wenn ihre Bedingung nicht als „true“ erkannt wird; siehe „Bedingte Includes“ weiter unten.

Sie können eine Konfigurationsdatei aus einer anderen Quelle einbinden, indem Sie die spezielle Variable include.path (oder includeIf.*.path) auf den Namen der einzubindenden Datei setzen. Die Variable nimmt einen Pfadnamen als Wert an und berücksichtigt die Tilde-Erweiterung. Diese Variablen können mehrfach angegeben werden.

Der Inhalt der eingebundenen Datei wird sofort eingefügt, so als ob er an der Stelle der Include-Anweisung gefunden worden wäre. Wenn der Wert der Variablen ein relativer Pfad ist, wird der Pfad als relativ zu der Konfigurationsdatei angesehen, in der die Include-Anweisung gefunden wurde. Siehe Beispiele weiter unten.

Bedingte Includes

Sie können eine Konfigurationsdatei aus einer anderen bedingt einbinden, indem Sie eine includeIf.<Bedingung>.path Variable auf den Namen der einzubindenden Datei setzen.

Die Bedingung beginnt mit einem Schlüsselwort, gefolgt von einem Doppelpunkt und einigen Daten, deren Format und Bedeutung vom Schlüsselwort abhängt. Gültige Schlüsselwörter sind:

gitdir

Die Daten, die dem Schlüsselwort gitdir: folgen, werden als Glob-Pattern verwendet. Wenn die Position des Verzeichnisses .git mit dem Pattern übereinstimmt, ist die Include-Bedingung erfüllt.

The .git location may be auto-discovered, or come from $GIT_DIR environment variable. If the repository is auto discovered via a .git file (e.g. from submodules, or a linked worktree), the .git location would be the final location where the .git directory is, not where the .git-Datei befindet.

Das Suchmuster kann Standard-Globbing-Platzhalter und zwei zusätzliche Platzhalter, **/ und /**, enthalten, die mit mehreren Pfadkomponenten übereinstimmen könnten. Bitte lesen Sie gitignore[5] für weitere Details. Der Einfachheit halber:

Beginnt das Pattern mit ~/, so wird das ~ durch den Inhalt der Umgebungsvariablen HOME ersetzt.
Beginnt das Pattern mit ./, so wird es durch das Verzeichnis ersetzt, das die aktuelle Konfigurationsdatei enthält.
Beginnt das Pattern weder mit ~/, ./ noch mit /, wird automatisch ein **/ vorangestellt. Zum Beispiel wird das Suchmuster foo/bar zu **/foo/bar und würde mit /irgendein/Pfad/zu/foo/bar übereinstimmen.
Endet das Pattern mit /, so wird automatisch ** hinzugefügt. Beispielsweise wird das Suchmuster foo/ zu foo/**. Mit anderen Worten, es stimmt rekursiv mit „foo“ und allem, was sich darin befindet, überein.

gitdir/i

Das entspricht gitdir, außer dass der Abgleich ohne Berücksichtigung von Groß- und Kleinschreibung erfolgt (z.B. auf Dateisystemen ohne diese Unterscheidung)

onbranch

Die Daten, die dem Schlüsselwort onbranch: folgen, werden als ein Pattern mit Standard-Globbing-Platzhaltern und zwei zusätzlichen Platzhaltern, **/ und /**, verstanden, die mit mehreren Pfadkomponenten übereinstimmen könnten. Wenn wir uns in einem Arbeitsbereich befinden, in dem der Name des Branches, der gerade ausgecheckt wird, mit dem Suchmuster übereinstimmt, ist die Include-Bedingung erfüllt.

Endet das Pattern mit /, wird automatisch ** hinzugefügt. Zum Beispiel wird das Muster foo/ zu foo/**. Mit anderen Worten, es passt auf alle Branches, die mit foo/ beginnen. Das ist dann hilfreich, wenn Ihre Branches hierarchisch organisiert sind und Sie eine Konfiguration auf alle Branches in dieser Hierarchie anwenden möchten.

Noch ein paar Anmerkungen zum Vergleichen über gitdir und gitdir/i:

Symlinks in $GIT_DIR werden vor dem Abgleich nicht ausgewertet.
Sowohl die Symlink- als auch die Realpfad-Versionen der Pfadangaben werden außerhalb von $GIT_DIR abgeglichen. Wenn z.B. ~/git ein Symlink zu /mnt/storage/git wäre, dann würden beide Versionen von gitdir:~/git und gitdir:/mnt/storage/git übereinstimmen.

Dies war bei der ursprünglichen Version dieses Features in v2.13.0 nicht der Fall, welche nur der realpath-Version entsprochen hat. Eine Konfiguration, die mit der ursprünglichen Version dieses Features kompatibel sein will, muss entweder nur die realpath-Version oder beide Versionen angeben.
Beachten Sie, dass "../" nichts Besonderes ist und wortwörtlich übereinstimmen wird, was vermutlich nicht das ist, was Sie erreichen wollen.

Beispiel

# Kernvariablen
[core]
	; Vertraue den Dateimodi nicht
	filemode = false

# Unser diff-Algorithmus
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

[branch "devel"]
	remote = origin
	merge = refs/heads/devel

# Proxyeinstellungen
[core]
	gitProxy="ssh" for kernel.org
	gitProxy=default-proxy ; für den Rest

[include]
	path = /path/to/foo.inc ; über den absoluten Pfad einbinden
	path = foo.inc ; finde "foo.inc" relativ zur aktuellen Datei
	path = ~/foo.inc ; finde "foo.inc" im `$HOME` Verzeichnis

; einbinden, falls $GIT_DIR /Pfad/zu/foo/.git ist
[includeIf "gitdir:/Pfad/zu/foo/.git"]
	path = /Pfad/zu/foo.inc

; alle Repositories innerhalb von /Pfad/zur/Gruppe einbinden
[includeIf "gitdir:/Pfad/zur/Gruppe"]
	path = /Pfad/zu/foo.inc

; einbinden, für alle Repositorys innerhalb von $HOME/zur/Gruppe
[includeIf "gitdir:~/zur/Gruppe/"]
	path = /Pfad/zu/foo.inc

; relative Pfade sind immer relativ zu der einschließenden
; Datei (wenn die Bedingung wahr ist); ihr Speicherort
; wird von der Bedingung nicht beeinflusst
[includeIf "gitdir:/Pfad/zur/Gruppe/"]
	path = foo.inc

; nur dann einbinden, wenn wir uns in einem Arbeitsbereich
; befinden, in dem foo-branch gerade ausgecheckt wird
[includeIf "onbranch:foo-branch"]
	path = foo.inc

Werte

Die Werte vieler Variablen werden als einfache Zeichenfolge behandelt, aber es gibt Variablen, die Werte bestimmter Typen annehmen und es gibt Richtlinien, wie sie zu formulieren sind.

boolean

Wenn eine Variable einen Wahrheitswert annehmen soll, werden viele Synonyme für true oder false akzeptiert; Groß- und Kleinschreibung wird dabei nicht beachtet.

true: Boolean true literals are yes, on, true, and 1. Also, a variable defined without = <value> is taken as true.
false: Boolean false literals are no, off, false, 0 and the empty string.

Bei der Konvertierung eines Wertes in seine kanonische Form unter Verwendung des --type=bool Typ-Bezeichners wird git config die Ausgabe "true" oder "false" (in Kleinbuchstaben geschrieben) ausgeben.

integer

Der Wert für viele Variablen, die unterschiedliche Größen angeben, kann mit den Suffixen k, M, … versehen werden. Das bedeutet, dass die Zahl "mit 1024", "mit 1024x1024", … skaliert wird.

color

Der Wert für eine Variable, die eine Farbe darstellt, ist eine durch Leerzeichen getrennte Liste von Farben (maximal zwei, einmal Vordergrund und einmal Hintergrund) und von Attributen (unbegrenzt viele).

The basic colors accepted are normal, black, red, green, yellow, blue, magenta, cyan, white and default. The first color given is the foreground; the second is the background. All the basic colors except normal and default have a bright variant that can be specified by prefixing the color with bright, like brightred.

The color normal makes no change to the color. It is the same as an empty string, but can be used as the foreground color when specifying a background color alone (for example, "normal red").

The color default explicitly resets the color to the terminal default, for example to specify a cleared background. Although it varies between terminals, this is usually not the same as setting to "white black".

Farben können auch als Zahlen zwischen 0 und 255 angegeben werden; diese verwenden den ANSI-256-Farbmodus (beachten Sie jedoch, dass dies möglicherweise nicht von allen Terminals unterstützt wird). Wenn Ihr Terminal dies unterstützt, können Sie auch 24-bit RGB-Werte als Hex-Wert angeben, wie z.B. #ff0ab3.

Die akzeptierten Attribute sind bold, dim, ul, blink, reverse, italic und strike (für durchgekreuzte oder durchgestrichene Zeichen). Die Position jeglicher Attribute in Bezug auf die Farben (vor, nach oder zwischen den Farben) spielt keine Rolle. Bestimmte Attribute können abgeschaltet werden, indem man ihnen no oder no- voranstellt (z.B. noreverse, no-ul, usw.).

The pseudo-attribute reset resets all colors and attributes before applying the specified coloring. For example, reset green will result in a green foreground and default background without any active attributes.

Ein leerer Farb-String erzeugt überhaupt keinen Farbeffekt. Damit kann das Einfärben bestimmter Elemente vermieden werden, ohne die Farbe vollständig zu deaktivieren.

Für die vordefinierten Farbslots von Git sollen die Attribute am Anfang jedes Elements in der farbigen Ausgabe zurückgesetzt werden. Wenn Sie also color.decorate.branch auf black setzen, wird dieser Branch-Name in schlichtem „schwarz“ dargestellt, selbst wenn die vorherige Sache in der gleichen Ausgabezeile (z.B. öffnende Klammer vor der Liste der Branch-Namen in der log --decorate Ausgabe) mit bold oder einem anderen Attribut dargestellt wird. Benutzerdefinierte Protokollformate können jedoch eine kompliziertere und überlagerte Farbgebung bewirken, und die negierten Formen könnten dort nützlich sein.

pathname

Einer Variablen, die einen Pfadnamen-Wert annimmt, kann ein String übergeben werden, der mit "~/" oder "~user/" beginnt. Die übliche Tilde-Erweiterung kommt bei einem solchen String zur Anwendung: ~/ wird auf den Wert von $HOME erweitert, und ~user/ auf das Home-Verzeichnis des angegebenen Benutzers.

If a path starts with %(prefix)/, the remainder is interpreted as a path relative to Git’s "runtime prefix", i.e. relative to the location where Git itself was installed. For example, %(prefix)/bin/ refers to the directory in which the Git executable itself lives. If Git was compiled without runtime prefix support, the compiled-in prefix will be substituted instead. In the unlikely event that a literal path needs to be specified that should not be expanded, it needs to be prefixed by ./, like so: ./%(prefix)/bin.

Variablen

Beachten Sie, dass diese Liste nicht ausführlich und nicht unbedingt vollständig ist. Für kommando-spezifische Variablen finden Sie eine ausführlichere Beschreibung in der entsprechenden Manpage.

Andere Git-Tools können und werden ihre eigenen Variablen verwenden. Wenn Sie neue Variablen für die Verwendung in Ihrem eigenen Dienstprogramm entwickeln, stellen Sie sicher, dass deren Namen nicht in Konflikt mit denen stehen, die von Git selbst und anderen beliebten Hilfsprogrammen verwendet werden. Beschreiben Sie diese Variablen in Ihrer Dokumentation.

Warning

Missing de/config/advice.txt