8.1 Git einrichten - Git Konfiguration

Um Ihre Commit- und Tag-Beschreibungen erstellen/bearbeiten zu können verwendet Git das von Ihnen als Standard-Text-Editor eingestellte Programm aus einer der Shell-Umgebungs-Variablen VISUAL oder EDITOR. Alternativ greift Git auf den vi-Editor zurück. Diesen Standard können Sie ändern, indem Sie die Einstellung core.editor verwenden:

Jetzt wird Git Emacs starten, unabhängig davon, was als Standard-Shell-Editor eingestellt ist, um die Beschreibungen zu bearbeiten.

Wenn Sie dieses Attribut auf die Pfadangabe einer Datei auf Ihrem System setzen, verwendet Git diese Datei als initiale Standard-Nachricht, wenn Sie einen Commit durchführen. Der Vorteil bei der Erstellung einer benutzerdefinierten Commit-Vorlage besteht darin, dass Sie sie verwenden können, um sich (oder andere) beim Erstellen einer Commit-Nachricht an das richtige Format und den richtigen Stil zu erinnern.

Nehmen wir z.B. eine Template-Datei unter ~/.gitmessage.txt, die so aussieht:

Beachten Sie, wie diese Commit-Vorlage den Committer daran erinnert, die Betreffzeile kurz zu halten (für die git log --oneline Ausgabe), weitere Details hinzuzufügen und sich auf ein Problem oder eine Bug-Tracker-Ticketnummer zu beziehen, falls vorhanden.

Um Git anzuweisen, das als Standardnachricht zu verwenden, die in Ihrem Editor erscheint, wenn Sie git commit ausführen, setzen Sie den Konfigurationswert commit.template:

Dann öffnet sich Ihr Text-Editor in etwa so für Ihre platzhaltergemäße Commit-Beschreibung, wenn Sie committen:

Mit einer eigenen Regel für Commit-Beschreibungen und dem Einfügen einer entsprechenden Vorlage in die Git-Konfiguration Ihres Systems erhöht sich die Wahrscheinlichkeit, dass diese Regel regelmäßig eingehalten wird.

Diese Einstellung bestimmt, welcher Pager genutzt werden soll, wenn git den Output von log und diff seitenweise ausgeben soll. Den Wert kann auf more oder wie von Ihnen bevorzugt eingestellt werden (Standard ist less). Sie können ihn deaktivieren, indem Sie eine leere Zeichenkette verwenden:

Wenn Sie das benutzen, wird Git die komplette Ausgabe aller Befehle abrufen, unabhängig davon, wie lang sie sind.

Wenn Sie signierte annotierte Tags erstellen (wie in Kapitel 7, Ihre Arbeit signieren beschrieben), erleichtert die Definition Ihres GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit. Stellen Sie Ihre Schlüssel-ID so ein:

Jetzt können Sie Tags signieren, ohne jedes Mal Ihren Schlüssel mit dem Befehl git tag angeben zu müssen:

Sie können Suchmuster in die .gitignore Datei Ihres Projekts einfügen. Damit können Sie verhindern, dass Git, so bestimmte Dateien, als nicht in der Versionsverwaltung erfasste Dateien erkennt oder sie zum Commit vormerkt, wenn Sie git add darauf ausführen, wie in Kapitel 2, Ignorieren von Dateien beschrieben.

In manchen Fällen sollen bestimmte Dateien für alle Repositorys ignoriert werden, in denen Sie arbeiten. Falls Sie macOS verwenden, kennen Sie vermutlich die .DS_Store Dateien. Bei Emacs oder Vim kennen Sie Dateinamen, die mit einer Tilde (~) oder auf .swp enden.

Mit dieser Einstellung können Sie eine gewisse, globale .gitignore Datei schreiben. Erstellen Sie eine ~/.gitignore_global Datei mit diesem Inhalt:

… und Sie führen git config --global core.excludesfile ~/.gitignore_global aus. Git wird sich nie wieder um diese Dateien kümmern.

Wenn Sie einen Befehl vertippen, zeigt das System Ihnen so etwas wie das hier:

Git versucht behilflich zu sein, um herauszufinden, was Sie gemeint haben, aber es verweigert es immer noch die Ausführung. Wenn Sie help.autocorrect auf 1 setzen, dann führt Git diesen Befehl tatsächlich aus:

Beachten Sie die „0,1 Sekunden“ Aktivität. help.autocorrect ist eigentlich eine Ganzzahl, die Zehntelsekunden repräsentiert. Wenn Sie den Wert auf 50 setzen, gibt Ihnen Git 5 Sekunden Zeit, Ihre Meinung zu ändern, bevor der autokorrigierte Befehl ausgeführt wird.

Git färbt den größten Teil seiner Ausgabe automatisch ein, aber es gibt einen Hauptschalter, wenn Ihnen dieses Verhalten nicht gefällt. Um alle farbigen Terminalausgaben von Git auszuschalten, verfahren Sie wie folgt:

Die Standardeinstellung ist auto, das die Ausgabe von Farben ausgibt, wenn es direkt zu einem Terminal geht, aber die Farbkontrollcodes weglässt, wenn die Ausgabe in eine Pipe oder eine Datei umgeleitet wird.

Sie können es auch auf always einstellen, dass der Unterschied zwischen Terminals und Pipes immer ignoriert wird. Das werden Sie nur selten wollen; in den meisten Szenarien können Sie stattdessen ein --color Flag an den Git-Befehl übergeben, um ihn zu zwingen, Farbcodes zu verwenden, wenn Sie Farbcodes in Ihrer umgeleiteten Ausgabe wünschen. Die Voreinstellung ist fast immer die richtige.

Wenn Sie genauer bestimmen möchten, welche Befehle wie eingefärbt werden, dann bietet Git spezifische Farbeinstellungen. Die einzelnen Befehle können auf true, false, oder always gesetzt werden:

Darüber hinaus hat jede dieser Optionen Untereinstellungen, mit denen Sie bestimmte Farben für Teile der Ausgabe festlegen können, wenn Sie die Farben überschreiben wollen. Um beispielsweise die Metainformationen in Ihrer Diff-Ausgabe auf blauen Vordergrund, schwarzen Hintergrund und fetten Text zu setzen, können Sie Folgendes ausführen:

Sie können die Farbe auf einen der folgenden Werte setzen: normal, black, red, green, yellow, blue, magenta, cyan oder white. Wenn Sie ein Attribut wie im vorherigen Beispiel fett wünschen, können Sie zwischen bold (fett), dim (abgedunkelt), ul (unterstrichen), blink (blinken) und reverse (Vorder- und Hintergrund vertauschen) wählen.

Wenn Sie unter Windows programmieren und mit Leuten arbeiten, die andere Systeme verwenden (oder umgekehrt), werden Sie wahrscheinlich irgendwann auf Probleme mit den Zeilenenden treffen. Der Grund hierfür ist, dass Windows in seinen Dateien sowohl ein Carriage-Return-Zeichen als auch ein Linefeed-Zeichen für Zeilenumbrüche verwendet, während macOS- und Linux-Systeme nur das Linefeed-Zeichen verwenden. Viele Editoren unter Windows ersetzen im Hintergrund bestehende Zeilenenden im LF-Stil durch CRLF oder fügen beide Zeilenendezeichen ein, wenn der Benutzer die Eingabetaste drückt.

Git kann das durch automatische Konvertierung von CRLF-Zeilenenden in LF übernehmen, wenn Sie eine Datei zum Index hinzufügen, und umgekehrt, wenn es Code auf Ihr Dateisystem auscheckt. Sie können diese Funktionen mit der core.autocrlf Einstellung einschalten. Wenn Sie sich auf einem Windows-Computer befinden, setzen Sie die Einstellung auf true – das konvertiert LF-Endungen in CRLF, wenn Sie Code auschecken:

Auf einem Linux- oder macOS-System, das LF-Zeilenenden verwendet, sollten Sie nicht zulassen, dass Git Dateien automatisch konvertiert, wenn Sie sie auschecken. Falls jedoch versehentlich eine Datei mit CRLF-Endungen hinzugefügt wird, können Sie dafür sorgen, dass Git sie korrigiert. Sie können Git anweisen, CRLF beim Commit in LF zu konvertieren, aber nicht umgekehrt, indem Sie core.autocrlf auf input setzen:

Dieses Setup sollte Ihnen CRLF-Endungen in Windows-Checkouts geben, aber LF-Endungen auf macOS- und Linux-Systemen und im Repository.

Wenn Sie ein Windows-Programmierer sind, der ein reines Windows-Projekt durchführt, dann können Sie diese Funktionalität deaktivieren und die Carriage Returns im Repository aufzeichnen, indem Sie den Konfigurationswert auf false setzen:

Git wird ursprünglich mit einer Voreinstellung zur Erkennung und Behebung einiger Leerzeichen-Probleme gestartet. Es kann nach sechs primären Leerzeichen-Problemen suchen – drei sind standardmäßig aktiviert und können deaktiviert werden, und drei sind standardmäßig deaktiviert, können aber aktiviert werden.

Die drei, bei denen die Standardeinstellung eingeschaltet ist, sind blankk-at-eol, das nach Leerzeichen am Ende einer Zeile sucht; blankk-at-eof, das leere Zeilen am Ende einer Datei bemerkt und space-before-tab, das nach Leerzeichen vor Tabulatoren am Anfang einer Zeile sucht.

Die drei, die standardmäßig deaktiviert sind, aber eingeschaltet werden können, sind indent-with-non-tab, das nach Zeilen sucht, die mit Leerzeichen anstelle von Tabs beginnen (und von der Option tabwidth kontrolliert werden); tab-in-indent, das nach Tabs im Einzug einer Zeile sucht und cr-at-eol, das Git mitteilt, dass Carriage Returns am Ende von Zeilen OK sind.

Sie können mit Git bestimmen, welche dieser Optionen aktiviert werden sollen. Setzen Sie dazu, getrennt durch Kommas, core.whitespace auf den gewünschten Wert (ein oder aus). Sie können eine Option deaktivieren, indem Sie ein - (Minus-Zeichen) dem Namen voranstellen, oder den Standardwert verwenden, indem Sie ihn ganz aus der Zeichenkette der Einstellung entfernen. Wenn Sie z.B. möchten, dass alles außer space-before-tab gesetzt wird, können Sie das so machen (wobei trailing-space eine Kurzform ist, um sowohl blank-at-eol als auch blank-at-eof abzudecken):

Oder Sie können nur den anzupassenden Teil angeben:

Git wird diese Punkte erkennen, wenn Sie einen git diff Befehl ausführen und versuchen sie einzufärben, damit Sie sie gegebenenfalls vor der Übertragung beheben können. Es wird diese Werte auch verwenden, um Ihnen zu helfen, wenn Sie Patches mit git apply einspielen. Wenn Sie Patches installieren, können Sie Git bitten, Sie zu warnen, wenn es Patches mit den angegebenen Leerzeichen-Problemen anwendet:

Sie können auch Git versuchen lassen, das Problem automatisch zu beheben, bevor Sie den Patch einspielen:

Diese Optionen gelten auch für den Befehl git rebase. Wenn Sie Leerzeichen-Probleme committet haben, aber noch nicht zum Upstream geschoben haben, können Sie git rebase --whitespace=fix ausführen, damit Git Leerzeichen-Probleme automatisch behebt, während es die Patches neu schreibt.

Git ist in der Lage zu kontrollieren, ob jedes während eines Pushs empfangene Objekt noch mit seiner SHA-1-Prüfsumme übereinstimmt und auf gültige Objekte zeigt. Standardmäßig tut es das jedoch nicht; es ist eine ziemlich aufwändige Operation und kann den Betrieb verlangsamen, insbesondere bei großen Repositorys oder Pushes. Wenn Sie möchten, dass Git bei jedem Push die Objektkonsistenz überprüft, können Sie es dazu zwingen, indem Sie receive.fsckObjects auf true setzen:

Jetzt prüft Git die Integrität Ihres Repositorys, noch bevor jeder Push akzeptiert wird, um sicherzustellen, dass fehlerhafte (oder böswillige) Clients keine schädlichen Daten eingeben.

Wenn Sie Commits rebasieren, die Sie bereits gepusht haben, und dann versuchen, erneut zu pushen, oder anderweitig versuchen, einen Commit an einen Remote-Branch zu senden, der nicht den Commit enthält, auf den der Remote-Zweig aktuell zeigt, werden Sie abgelehnt. Im Allgemeinen ist das eine gute Richtlinie. Bei dem Rebase können Sie festlegen den Remote-Branch mit einem -f Flag in Ihrem Push-Befehl zu aktualisieren, wenn Sie wissen, was Sie tun.

Um Git anzuweisen, Force-Pushes abzulehnen, setzen Sie receive.denyNonFastForwards:

Die andere Möglichkeit ist, dass Sie das über serverseitige Receive-Hooks tun, die wir im weiteren Verlauf behandeln werden. Dieser Ansatz ermöglicht es Ihnen, komplexere Dinge zu tun, wie z.B. einem bestimmten Teil der Benutzer die Möglichkeit „non-fast-forwards“ zu verweigern.

Ein möglicher Workaround für die denyNonFastForwards Regel besteht darin, dass der Benutzer den Branch löscht und ihn dann mit einer neuen Referenz wieder nach oben pusht. Um das zu verhindern, setzen Sie receive.denyDeletes auf true:

Dadurch wird das Löschen von Branches oder Tags verhindert – kein User darf das anwenden. Um dann Remote-Branches zu entfernen, müssen Sie die ref-Dateien manuell vom Server entfernen. Es gibt weitere interessante Möglichkeiten, das auf Benutzerebene über ACLs zu realisieren, wie Sie in Beispiel für Git-forcierte Regeln erfahren werden.