8.1 Git einrichten - Git Konfiguration

Um deine Commit- und Tag-Beschreibungen erstellen/bearbeiten zu können verwendet Git das von dir 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 kannst du ändern, indem du die Einstellung core.editor verwendest:

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

Wenn du dieses Attribut auf die Pfadangabe einer Datei auf deinem System setzt, verwendet Git diese Datei als initiale Standard-Nachricht, wenn du einen Commit durchführst. Der Vorteil bei der Erstellung einer benutzerdefinierten Commit-Vorlage besteht darin, dass du sie verwenden kannst, 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:

Diese Commit-Vorlage erinnert den Committer daran, 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 deinem Editor erscheint, wenn du git commit ausführst, setze den Konfigurationswert commit.template:

Dann öffnet sich dein Text-Editor in etwa so für deine Commit-Beschreibung, wenn du committest:

Mit einer eigenen Regel für Commit-Beschreibungen und dem Einfügen einer entsprechenden Vorlage in die Git-Konfiguration deines 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 dir bevorzugt eingestellt werden (Standard ist less). Du kannst ihn deaktivieren, indem du eine leere Zeichenkette verwendest:

Wenn du diese Konfiguration nutzt, wird Git die komplette Ausgabe aller Befehle anzeigen, unabhängig davon, wie lang sie sind.

Wenn du signierte und annotierte Tags erstellst (wie in Kapitel 7, Ihre Arbeit signieren beschrieben), erleichtert die Definition deines GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit. Stelle deine Schlüssel-ID so ein:

Jetzt kannst du Tags signieren, ohne jedes Mal deinen Schlüssel mit dem Befehl git tag angeben zu müssen:

Du kannst Suchmuster in die .gitignore Datei deines Projekts einfügen. Damit kannst du verhindern, dass Git bestimmte Dateien als nicht in der Versionsverwaltung erfasste Dateien erkennt und sie zum Commit vormerken will, wenn du git add darauf ausführst, wie in Kapitel 2, Ignorieren von Dateien beschrieben.

In manchen Fällen sollen bestimmte Dateien für alle Repositorys ignoriert werden, in denen du arbeitest. Falls du macOS verwendest, kennst du vermutlich die .DS_Store Dateien. Bei Emacs oder Vim kennst du vielleicht Dateien, die mit einer Tilde (~) oder auf .swp enden.

Mit dieser Einstellung kannst du eine Art globale .gitignore Datei schreiben. Erstelle eine ~/.gitignore_global Datei mit diesem Inhalt:

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

Wenn du dich bei einem Befehl vertippst, zeigt das System dir so etwas wie das hier:

Git hilft dir dabei herauszufinden, was du gemeint hast, aber es führt den Befehl nicht aus. Wenn du help.autocorrect auf 1 setzt, dann führt Git den vorgeschlagenen Befehl auch aus:

Beachte die „0,1 Sekunden“ Angabe. help.autocorrect ist eigentlich eine Ganzzahl, die Zehntelsekunden repräsentiert. Wenn du den Wert auf 50 setzt, gibt dir Git 5 Sekunden Zeit deine 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 dir dieses Verhalten nicht gefällt. Um alle farbigen Terminalausgaben von Git auszuschalten, nutze Folgendes:

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.

Du kannst es auch auf always einstellen, dass der Unterschied zwischen Terminals und Pipes ignoriert. Das willst du in der Regel nicht. In den meisten Szenarien kannst du stattdessen ein --color Flag an den Git-Befehl übergeben, um ihn zu zwingen, Farbcodes zu verwenden, wenn du Farbcodes in deine umgeleiteten Ausgabe wünschst. Die Voreinstellung ist fast immer die Richtige.

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

Darüber hinaus hat jede dieser Optionen Untereinstellungen, mit denen du bestimmte Farben für Teile der Ausgabe festlegen kannst, falls du die Farben überschreiben willst. Um beispielsweise die Metainformationen in deiner Diff-Ausgabe auf blauen Vordergrund, schwarzen Hintergrund und fetten Text zu setzen, kannst du Folgendes ausführen:

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

Wenn du unter Windows programmierst und mit Leuten arbeitest, die andere Systeme verwenden (oder umgekehrt), wirst du 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 du eine Datei zum Index hinzufügest, und umgekehrt, wenn es Code auf dein Dateisystem auscheckt. Du kannst diese Funktionen mit der core.autocrlf Einstellung einschalten. Wenn du dich auf einem Windows-Computer befindest, setze die Einstellung auf true. das konvertiert LF-Endungen in CRLF, wenn du Code auscheckst:

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

Dieses Setup sollte deine CRLF-Endungen in Windows-Checkouts nicht ändern, aber LF-Endungen auf macOS- und Linux-Systemen und im Repository.

Wenn du ein Windows-Programmierer bist, der ein reines Windows-Projekt durchführt, dann kannst du diese Funktionalität deaktivieren und die Carriage Returns im Repository aufzeichnen, indem du den Konfigurationswert auf false setzt:

Git wird von Hause aus mit einer Voreinstellung zur Erkennung und Behebung einiger Leerzeichen-Probleme installiert. 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 blank-at-eol, das nach Leerzeichen am Ende einer Zeile sucht; blank-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.

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

Oder du kannst nur den anzupassenden Teil angeben:

Git wird diese Punkte erkennen, wenn du einen git diff Befehl ausführst und versuchen sie einzufärben, damit du sie gegebenenfalls vor dem Commit beheben kannst. Git wird diese Werte auch verwenden, um dir zu helfen, wenn du Patches mit git apply einspielst. Wenn du Patches installieren, kannst du Git bitten, dich zu warnen, wenn es Patches mit den angegebenen Leerzeichen-Problemen anwendet:

Du kannst auch Git versuchen lassen, das Problem automatisch zu beheben, bevor du den Patch einspielst:

Diese Optionen gelten auch für den Befehl git rebase. Wenn du Leerzeichen-Probleme committet hast, aber noch nicht zum Upstream gepusht hast, kannst du 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 du möchtest, dass Git bei jedem Push die Objektkonsistenz überprüft, kannst du es dazu zwingen, indem du receive.fsckObjects auf true setzt:

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

Wenn du Commits rebased, die du bereits gepusht hast, und dann versuchst, erneut zu pushen, oder anderweitig versuchst, einen Commit an einen Remote-Branch zu senden, der nicht den Commit enthält, auf den der Remote-Branch aktuell zeigt, wird dies abgelehnt. Im Allgemeinen ist das eine gute Richtlinie. Bei dem Rebase kannst du festlegen den Remote-Branch mit einem -f Flag in deinem Push-Befehl zu aktualisieren, wenn du weißt, was du tust.

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

Die andere Möglichkeit ist, das über serverseitige Receive-Hooks tun, die wir im weiteren Verlauf behandeln werden. Dieser Ansatz ermöglicht es dir, 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 pusht. Um das zu verhindern, setze receive.denyDeletes auf true:

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