Kapitel ▾ 2. Auflage

8.1 Git anpassen - Git-Konfiguration

Bisher haben wir die Grundlagen von Git behandelt und wie man es benutzt, und wir haben eine Reihe von Werkzeugen vorgestellt, die Git zur Verfügung stellt, um die Benutzung einfach und effizient zu gestalten. In diesem Kapitel werden wir sehen, wie Sie Git auf eine stärker angepasste Weise betreiben können, indem wir mehrere wichtige Konfigurationseinstellungen und das Hooks-System einführen. Mit diesen Werkzeugen ist es einfach, Git genau so arbeiten zu lassen, wie Sie, Ihr Unternehmen oder Ihre Gruppe es benötigen.

Git-Konfiguration

Wie Sie kurz in Erste Schritte gelesen haben, können Sie Git-Konfigurationseinstellungen mit dem Befehl git config festlegen. Eines der ersten Dinge, die Sie getan haben, war die Einrichtung Ihres Namens und Ihrer E-Mail-Adresse

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Nun lernen Sie einige der interessanteren Optionen kennen, die Sie auf diese Weise einstellen können, um Ihre Git-Nutzung anzupassen.

Zuerst eine kurze Wiederholung: Git verwendet eine Reihe von Konfigurationsdateien, um nicht standardmäßiges Verhalten zu bestimmen, das Sie vielleicht wünschen. Der erste Ort, an dem Git nach diesen Werten sucht, ist die systemweite Datei [path]/etc/gitconfig, die Einstellungen enthält, die für jeden Benutzer auf dem System und alle seine Repositories gelten. Wenn Sie die Option --system an git config übergeben, liest und schreibt es speziell aus dieser Datei.

Der nächste Ort, an dem Git sucht, ist die Datei ~/.gitconfig (oder ~/.config/git/config), die benutzerspezifisch ist. Sie können Git veranlassen, aus dieser Datei zu lesen und in sie zu schreiben, indem Sie die Option --global übergeben.

Schließlich sucht Git nach Konfigurationswerten in der Konfigurationsdatei im Git-Verzeichnis (.git/config) des jeweiligen Repositorys, das Sie gerade verwenden. Diese Werte sind spezifisch für dieses einzelne Repository und repräsentieren die Übergabe der Option --local an git config. Wenn Sie keine Ebene angeben, mit der Sie arbeiten möchten, ist dies die Standardeinstellung.

Jede dieser "Ebenen" (systemweit, global, lokal) überschreibt Werte der vorherigen Ebene, sodass Werte in .git/config beispielsweise diejenigen in [path]/etc/gitconfig übertrumpfen.

Hinweis

Die Konfigurationsdateien von Git sind reine Textdateien, sodass Sie diese Werte auch durch manuelles Bearbeiten der Datei und Einfügen der richtigen Syntax festlegen können. Es ist jedoch im Allgemeinen einfacher, den Befehl git config auszuführen.

Grundlegende Client-Konfiguration

Die von Git erkannten Konfigurationsoptionen fallen in zwei Kategorien: Client-seitig und Server-seitig. Die Mehrheit der Optionen ist Client-seitig – sie konfigurieren Ihre persönlichen Arbeitseinstellungen. Viele, *viele* Konfigurationsoptionen werden unterstützt, aber ein großer Teil davon ist nur in bestimmten Ausnahmefällen nützlich; wir behandeln hier nur die gebräuchlichsten und nützlichsten Optionen. Wenn Sie eine Liste aller Optionen sehen möchten, die Ihre Git-Version erkennt, können Sie Folgendes ausführen:

$ man git-config

Dieser Befehl listet alle verfügbaren Optionen ziemlich detailliert auf. Sie finden diese Referenz auch unter https://git-scm.de/docs/git-config.

Hinweis

Für fortgeschrittene Anwendungsfälle sollten Sie "Conditional includes" in der oben genannten Dokumentation nachschlagen.

core.editor

Standardmäßig verwendet Git den von Ihnen über eine der Shell-Umgebungsvariablen VISUAL oder EDITOR festgelegten Standardtexteditor oder greift auf den vi-Editor zurück, um Ihre Commit- und Tag-Nachrichten zu erstellen und zu bearbeiten. Um diesen Standard auf etwas anderes zu ändern, können Sie die Einstellung core.editor verwenden

$ git config --global core.editor emacs

Nun wird Git, unabhängig davon, was als Ihr Standard-Shell-Editor eingestellt ist, Emacs zum Bearbeiten von Nachrichten starten.

commit.template

Wenn Sie dies auf den Pfad einer Datei auf Ihrem System setzen, verwendet Git diese Datei als Standard-Initialnachricht, wenn Sie committen. Der Vorteil der Erstellung einer benutzerdefinierten Commit-Vorlage besteht darin, dass Sie sich (oder andere) an das richtige Format und den richtigen Stil erinnern können, wenn Sie eine Commit-Nachricht erstellen.

Betrachten Sie zum Beispiel eine Vorlagendatei unter ~/.gitmessage.txt, die wie folgt aussieht:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

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

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

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Dann öffnet sich Ihr Editor für Ihre Platzhalter-Commit-Nachricht, wenn Sie committen, etwa so:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

Wenn Ihr Team eine Richtlinie für Commit-Nachrichten hat, kann das Ablegen einer Vorlage für diese Richtlinie auf Ihrem System und die Konfiguration von Git, sie standardmäßig zu verwenden, die Wahrscheinlichkeit erhöhen, dass diese Richtlinie regelmäßig eingehalten wird.

core.pager

Diese Einstellung bestimmt, welcher Pager verwendet wird, wenn Git Ausgaben seitenweise anzeigt, wie z. B. log und diff. Sie können ihn auf more oder Ihren bevorzugten Pager setzen (standardmäßig ist es less) oder ihn deaktivieren, indem Sie ihn auf eine leere Zeichenfolge setzen

$ git config --global core.pager ''

Wenn Sie das ausführen, gibt Git die gesamte Ausgabe aller Befehle aus, egal wie lang sie sind.

user.signingkey

Wenn Sie signierte annotierte Tags erstellen (wie in Signieren Ihrer Arbeit beschrieben), erleichtert das Festlegen Ihres GPG-Signaturschlüssels als Konfigurationseinstellung die Dinge. Legen Sie Ihre Schlüssel-ID wie folgt fest:

$ git config --global user.signingkey <gpg-key-id>

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

$ git tag -s <tag-name>

core.excludesfile

Sie können Muster in die .gitignore-Datei Ihres Projekts einfügen, damit Git sie nicht als ungetrackte Dateien sieht oder versucht, sie zu stagen, wenn Sie git add darauf ausführen, wie in Dateien ignorieren beschrieben.

Aber manchmal möchten Sie bestimmte Dateien für alle Repositories ignorieren, mit denen Sie arbeiten. Wenn Ihr Computer macOS ausführt, sind Sie wahrscheinlich mit .DS_Store-Dateien vertraut. Wenn Ihr bevorzugter Editor Emacs oder Vim ist, kennen Sie Dateinamen, die mit ~ oder .swp enden.

Diese Einstellung ermöglicht es Ihnen, eine Art globale .gitignore-Datei zu schreiben. Wenn Sie eine Datei ~/.gitignore_global mit diesem Inhalt erstellen

*~
.*.swp
.DS_Store

…und Sie git config --global core.excludesfile ~/.gitignore_global ausführen, wird Git Sie nie wieder mit diesen Dateien belästigen.

help.autocorrect

Wenn Sie einen Befehl falsch eingeben, zeigt er Ihnen etwas wie das hier an:

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

The most similar command is
    checkout

Git versucht hilfsbereit herauszufinden, was Sie meinten, weigert sich aber dennoch, es auszuführen. Wenn Sie help.autocorrect auf 1 setzen, wird Git diesen Befehl tatsächlich für Sie ausführen:

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

Beachten Sie die Sache mit den "0,1 Sekunden". help.autocorrect ist eigentlich eine Ganzzahl, die Zehntelsekunden darstellt. Wenn Sie sie also auf 50 setzen, gibt Ihnen Git 5 Sekunden Zeit, Ihre Meinung zu ändern, bevor der korrigierte Befehl ausgeführt wird.

Farben in Git

Git unterstützt vollständig farbige Terminalausgaben, was die visuelle Analyse von Befehlsausgaben schnell und einfach erleichtert. Eine Reihe von Optionen kann Ihnen helfen, die Farbgebung nach Ihren Wünschen einzustellen.

color.ui

Git färbt die meisten seiner Ausgaben automatisch ein, aber es gibt einen Hauptschalter, wenn Ihnen dieses Verhalten nicht gefällt. Um alle Git-Terminalausgaben in Farbe auszuschalten, machen Sie Folgendes:

$ git config --global color.ui false

Die Standardeinstellung ist auto, die Ausgaben einfärbt, wenn sie direkt an ein Terminal gehen, aber die Farbsteuerungs-Codes weglässt, wenn die Ausgabe an eine Pipe oder eine Datei umgeleitet wird.

Sie können es auch auf always setzen, um den Unterschied zwischen Terminals und Pipes zu ignorieren. Das werden Sie selten wollen; in den meisten Szenarien, wenn Sie Farb-Codes in Ihrer umgeleiteten Ausgabe wünschen, können Sie stattdessen ein Flag --color an den Git-Befehl übergeben, um ihn zu zwingen, Farb-Codes zu verwenden. Die Standardeinstellung ist fast immer das, was Sie wollen werden.

color.*

Wenn Sie spezifischer sein möchten, welche Befehle eingefärbt werden und wie, bietet Git verb-spezifische Farbeneinstellungen. Jede dieser kann auf true, false oder always gesetzt werden.

color.branch
color.diff
color.interactive
color.status

Zusätzlich hat jede dieser Einstellungen Untereinstellungen, die Sie verwenden können, um spezifische Farben für Teile der Ausgabe festzulegen, wenn Sie eine Farbe überschreiben möchten. Zum Beispiel, um die Metainformationen in Ihrer Diff-Ausgabe auf blauem Vordergrund, schwarzem Hintergrund und fetter Schrift einzustellen, können Sie Folgendes ausführen:

$ git config --global color.diff.meta "blue black bold"

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 "bold" im vorherigen Beispiel wünschen, können Sie aus bold, dim, ul (underline), blink und reverse (Vorder- und Hintergrund vertauschen) wählen.

Externe Merge- und Diff-Tools

Obwohl Git eine interne Implementierung von Diff hat, die wir in diesem Buch gezeigt haben, können Sie stattdessen ein externes Tool einrichten. Sie können auch ein grafisches Tool zur Auflösung von Merge-Konflikten einrichten, anstatt Konflikte manuell auflösen zu müssen. Wir werden die Einrichtung des Perforce Visual Merge Tool (P4Merge) demonstrieren, um Ihre Diffs und Merge-Auflösungen durchzuführen, da es ein schönes grafisches Tool ist und kostenlos ist.

Wenn Sie dies ausprobieren möchten, funktioniert P4Merge auf allen wichtigen Plattformen, sodass Sie dies tun können. Wir verwenden Pfadnamen in den Beispielen, die auf macOS- und Linux-Systemen funktionieren; für Windows müssen Sie /usr/local/bin in einen ausführbaren Pfad in Ihrer Umgebung ändern.

Um zu beginnen, laden Sie P4Merge von Perforce herunter. Als Nächstes richten Sie externe Wrapper-Skripte ein, um Ihre Befehle auszuführen. Wir verwenden den macOS-Pfad für die ausführbare Datei; auf anderen Systemen wird es dort sein, wo Ihre p4merge-Binärdatei installiert ist. Richten Sie ein Merge-Wrapper-Skript namens extMerge ein, das Ihre Binärdatei mit allen übergebenen Argumenten aufruft:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

Der Diff-Wrapper prüft, ob sieben Argumente übergeben werden, und leitet zwei davon an Ihr Merge-Skript weiter. Standardmäßig übergibt Git die folgenden Argumente an das Diff-Programm:

path old-file old-hex old-mode new-file new-hex new-mode

Da Sie nur die Argumente old-file und new-file benötigen, verwenden Sie das Wrapper-Skript, um die benötigten Argumente zu übergeben.

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

Sie müssen auch sicherstellen, dass diese Tools ausführbar sind:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

Nun können Sie Ihre Konfigurationsdatei einrichten, um Ihre benutzerdefinierten Merge-Auflösungs- und Diff-Tools zu verwenden. Dies erfordert eine Reihe von benutzerdefinierten Einstellungen: merge.tool, um Git die zu verwendende Strategie mitzuteilen, mergetool.<tool>.cmd, um anzugeben, wie der Befehl ausgeführt werden soll, mergetool.<tool>.trustExitCode, um Git mitzuteilen, ob der Exit-Code dieses Programms eine erfolgreiche Merge-Auflösung anzeigt oder nicht, und diff.external, um Git mitzuteilen, welcher Befehl für Diffs ausgeführt werden soll. Sie können also entweder vier Konfigurationsbefehle ausführen:

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
  'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

oder Sie können Ihre Datei ~/.gitconfig bearbeiten, um diese Zeilen hinzuzufügen:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

Nachdem alles eingerichtet ist, wenn Sie Diff-Befehle wie diesen ausführen:

$ git diff 32d1776b1^ 32d1776b1

Anstatt die Diff-Ausgabe auf der Befehlszeile zu erhalten, startet Git P4Merge, das etwa so aussieht:

P4Merge
Abbildung 168. P4Merge

Wenn Sie versuchen, zwei Branches zu mergen und anschließend Merge-Konflikte auftreten, können Sie den Befehl git mergetool ausführen; er startet P4Merge, damit Sie die Konflikte über dieses GUI-Tool auflösen können.

Das Gute an dieser Wrapper-Einrichtung ist, dass Sie Ihre Diff- und Merge-Tools einfach ändern können. Zum Beispiel, um Ihre extDiff- und extMerge-Tools so zu ändern, dass sie stattdessen das KDiff3-Tool ausführen, müssen Sie nur Ihre extMerge-Datei bearbeiten:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

Nun wird Git das KDiff3-Tool zur Diff-Anzeige und zur Auflösung von Merge-Konflikten verwenden.

Git ist voreingestellt, um eine Reihe anderer Merge-Auflösungs-Tools zu verwenden, ohne dass Sie die cmd-Konfiguration einrichten müssen. Um eine Liste der unterstützten Tools anzuzeigen, versuchen Sie Folgendes:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

Wenn Sie KDiff3 nicht für Diffs, sondern nur für die Merge-Auflösung verwenden möchten und der Befehl kdiff3 in Ihrem Pfad ist, können Sie Folgendes ausführen:

$ git config --global merge.tool kdiff3

Wenn Sie dies anstelle der Einrichtung der Dateien extMerge und extDiff ausführen, verwendet Git KDiff3 für die Merge-Auflösung und das normale Git-Diff-Tool für Diffs.

Formatierung und Leerzeichen

Formatierungs- und Leerzeichenprobleme sind einige der frustrierendsten und subtilsten Probleme, auf die viele Entwickler bei der Zusammenarbeit stoßen, insbesondere plattformübergreifend. Es ist sehr einfach, dass Patches oder andere zusammengearbeitete Arbeiten subtile Leerzeichenänderungen einführen, da Editoren sie stillschweigend einführen, und wenn Ihre Dateien jemals ein Windows-System berühren, könnten ihre Zeilenenden ersetzt werden. Git verfügt über einige Konfigurationsoptionen, die bei diesen Problemen helfen.

core.autocrlf

Wenn Sie unter Windows programmieren und mit Leuten arbeiten, die dies nicht tun (oder umgekehrt), werden Sie wahrscheinlich irgendwann auf Probleme mit Zeilenenden stoßen. Das liegt daran, dass Windows sowohl ein Wagenrücklaufzeichen als auch ein Zeilenvorschubzeichen für Zeilenumbrüche in seinen Dateien verwendet, während macOS- und Linux-Systeme nur das Zeilenvorschubzeichen verwenden. Dies ist eine subtile, aber unglaublich ärgerliche Tatsache bei plattformübergreifender Arbeit; viele Editoren unter Windows ersetzen stillschweigend vorhandene LF-Stil-Zeilenenden durch CRLF oder fügen beide Zeilenendezeichen ein, wenn der Benutzer die Eingabetaste drückt.

Git kann dies handhaben, indem es CRLF-Zeilenenden automatisch in LF konvertiert, wenn Sie eine Datei zum Index hinzufügen, und umgekehrt, wenn es Code auf Ihr Dateisystem auscheckt. Sie können diese Funktionalität mit der Einstellung core.autocrlf aktivieren. Wenn Sie sich auf einem Windows-Computer befinden, setzen Sie sie auf true – dies konvertiert LF-Endungen in CRLF, wenn Sie Code auschecken:

$ git config --global core.autocrlf true

Wenn Sie sich auf einem Linux- oder macOS-System befinden, das LF-Zeilenenden verwendet, möchten Sie nicht, dass Git diese beim Auschecken von Dateien automatisch konvertiert; wenn jedoch versehentlich eine Datei mit CRLF-Endungen eingeführt wird, möchten Sie vielleicht, dass Git sie repariert. Sie können Git anweisen, CRLF in LF bei Commits zu konvertieren, aber nicht umgekehrt, indem Sie core.autocrlf auf input setzen:

$ git config --global core.autocrlf input

Diese Einrichtung sollte zu CRLF-Endungen bei Windows-Checkouts, aber zu LF-Endungen auf macOS- und Linux-Systemen und im Repository führen.

Wenn Sie ein Windows-Programmierer sind und nur ein Windows-Projekt entwickeln, können Sie diese Funktionalität deaktivieren und die Wagenrückläufe im Repository speichern, indem Sie den Konfigurationswert auf false setzen:

$ git config --global core.autocrlf false

core.whitespace

Git ist voreingestellt, um einige Leerzeichenprobleme zu erkennen und zu beheben. Es kann sechs Hauptprobleme mit Leerzeichen erkennen – drei sind standardmäßig aktiviert und können deaktiviert werden, und drei sind standardmäßig deaktiviert, können aber aktiviert werden.

Die drei, die standardmäßig aktiviert sind, sind blank-at-eol, das nach Leerzeichen am Ende einer Zeile sucht; blank-at-eof, das leere Zeilen am Ende einer Datei erkennt; und space-before-tab, das nach Leerzeichen vor Tabs am Anfang einer Zeile sucht.

Die drei, die standardmäßig deaktiviert sind, aber aktiviert werden können, sind indent-with-non-tab, das nach Zeilen sucht, die mit Leerzeichen statt mit Tabs beginnen (und durch die Option tabwidth gesteuert wird); tab-in-indent, das Tabs im Einrückungsbereich einer Zeile überwacht; und cr-at-eol, das Git mitteilt, dass Wagenrückläufe am Ende von Zeilen in Ordnung sind.

Sie können Git mitteilen, welche davon Sie aktivieren möchten, indem Sie core.whitespace auf die gewünschten Werte setzen, getrennt durch Kommas. Sie können eine Option deaktivieren, indem Sie ein - vor ihren Namen setzen, oder den Standardwert verwenden, indem Sie sie aus der Einstellungzeichenfolge weglassen. Wenn Sie beispielsweise alle bis auf space-before-tab setzen möchten, können Sie dies tun (wobei trailing-space eine Abkürzung ist, die sowohl blank-at-eol als auch blank-at-eof abdeckt):

$ git config --global core.whitespace \
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Oder Sie können nur den anpassbaren Teil angeben:

$ git config --global core.whitespace \
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Git erkennt diese Probleme, wenn Sie einen git diff-Befehl ausführen, und versucht, sie einzufärben, damit Sie sie möglicherweise beheben können, bevor Sie committen. Es verwendet diese Werte auch, um Ihnen zu helfen, wenn Sie Patches mit git apply anwenden. Wenn Sie Patches anwenden, können Sie Git bitten, Sie zu warnen, wenn es Patches mit den angegebenen Leerzeichenproblemen anwendet:

$ git apply --whitespace=warn <patch>

Oder Sie können Git versuchen lassen, das Problem automatisch zu beheben, bevor der Patch angewendet wird:

$ git apply --whitespace=fix <patch>

Diese Optionen gelten auch für den Befehl git rebase. Wenn Sie Leerzeichenprobleme committet, aber noch nicht nach oben gepusht haben, können Sie git rebase --whitespace=fix ausführen, um Git automatisch Leerzeichenprobleme beheben zu lassen, während es die Patches neu schreibt.

Serverkonfiguration

Es sind bei weitem nicht so viele Konfigurationsoptionen für die Serverseite von Git verfügbar, aber es gibt ein paar interessante, die Sie vielleicht beachten möchten.

receive.fsckObjects

Git ist in der Lage sicherzustellen, dass jedes beim Empfang eines Pushs erhaltene Objekt immer noch mit seinem SHA-1-Checksum übereinstimmt und auf gültige Objekte verweist. Standardmäßig tut es dies jedoch nicht; es ist ein ziemlich teurer Vorgang und kann die Operation verlangsamen, insbesondere bei großen Repositories oder Pushs. Wenn Sie möchten, dass Git die Objektkonsistenz bei jedem Push überprüft, können Sie es dazu zwingen, indem Sie receive.fsckObjects auf true setzen:

$ git config --system receive.fsckObjects true

Nun prüft Git die Integrität Ihres Repositories vor jedem akzeptierten Push, um sicherzustellen, dass fehlerhafte (oder böswillige) Clients keine beschädigten Daten einführen.

receive.denyNonFastForwards

Wenn Sie Commits, die Sie bereits gepusht haben, rebasen und dann erneut versuchen, sie zu pushen, oder anderweitig versuchen, einen Commit auf einen Remote-Branch zu pushen, der nicht den Commit enthält, auf den der Remote-Branch gerade zeigt, werden Sie abgewiesen. Dies ist im Allgemeinen eine gute Richtlinie; im Falle des Rebasings können Sie jedoch feststellen, dass Sie wissen, was Sie tun, und den Remote-Branch mit einem Flag -f zu Ihrem Push-Befehl erzwingen.

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

$ git config --system receive.denyNonFastForwards true

Der andere Weg, dies zu tun, ist über serverseitige Receive-Hooks, die wir gleich behandeln werden. Dieser Ansatz ermöglicht es Ihnen, komplexere Dinge zu tun, wie z. B. Nicht-Fast-Forwards für eine bestimmte Untergruppe von Benutzern abzulehnen.

receive.denyDeletes

Eine der Problemumgehungen für die Richtlinie denyNonFastForwards besteht darin, dass der Benutzer den Branch löscht und ihn dann mit der neuen Referenz wieder hochlädt. Um dies zu vermeiden, setzen Sie receive.denyDeletes auf true:

$ git config --system receive.denyDeletes true

Dies lehnt jede Löschung von Branches oder Tags ab – kein Benutzer kann dies tun. Um Remote-Branches zu entfernen, müssen Sie die Ref-Dateien manuell vom Server entfernen. Es gibt auch interessantere Möglichkeiten, dies pro Benutzer über ACLs zu tun, wie Sie in Ein Beispiel für eine Git-erzwungene Richtlinie lernen werden.