Git-Benutzerkonfiguration meistern: Name, E-Mail und Editor-Standardeinstellungen

Die Git-Benutzerkonfiguration wirkt langweilig, bis Ihre Arbeits-Commits zum ersten Mal unter der falschen E-Mail-Adresse auftauchen, Ihr Unternehmensbeitragsgraph die Hälfte Ihrer Änderungen vermisst oder Git einen Editor öffnet, den Sie nicht zu schließen wissen. Die Lösung ist normalerweise einfach: Setzen Sie Ihren Namen, Ihre E-Mail und Ihren Editor bewusst und wissen Sie, wie Sie diese für ein einzelnes Repository überschreiben können.

Der wichtige Teil ist nicht, jedes git config-Flag auswendig zu lernen. Es geht darum zu verstehen, wo Git die Konfiguration liest und wie Sie den endgültigen Wert überprüfen, den Git verwenden wird, bevor Sie einen Commit erstellen.

Git-Konfigurationsebenen verstehen

Git verwendet eine Hierarchie von Konfigurationsdateien. Einstellungen, die auf einer höheren Ebene definiert sind, können durch Einstellungen auf einer niedrigeren Ebene überschrieben werden. Das Verständnis dieser Ebenen ermöglicht es Ihnen, Einstellungen granular oder universell anzuwenden.

Es gibt drei primäre Konfigurationsebenen:

Systemebene (--system): Gilt für jeden Benutzer und jedes Repository auf dem gesamten Rechner. Dies wird selten für die Benutzeridentität verwendet, es sei denn, Sie verwalten einen dedizierten Build-Server.
Globale Ebene (--global): Gilt für alle Repositorys, die dem aktuellen Benutzer auf dem Rechner gehören. Hier setzen Sie normalerweise Ihren primären user.name und user.email.
Lokale Ebene (--local): Gilt nur für das spezifische Repository, in dem Sie sich gerade befinden. Dies ermöglicht es Ihnen, eine andere Identität für ein bestimmtes Projekt zu verwenden (z. B. Arbeit vs. privat).

Aktuelle Konfigurationseinstellungen anzeigen

Bevor Sie Änderungen vornehmen, ist es hilfreich zu sehen, was Git derzeit verwendet. Sie können Einstellungen für alle Ebenen oder nur für eine bestimmte auflisten:

# Alle Einstellungen über alle Ebenen hinweg anzeigen
git config --list

# Nur globale Einstellungen anzeigen
git config --global --list

Konfigurieren Ihrer Benutzeridentität (Name und E-Mail)

Ihr Name und Ihre E-Mail-Adresse sind die wichtigsten Benutzerinformationen, die in Git gespeichert werden. Sie identifizieren, wer die Änderung vorgenommen hat.

1. Globale Benutzeridentität festlegen

Für die meisten Benutzer ist das globale Festlegen von Name und E-Mail der empfohlene erste Schritt. Dadurch wird sichergestellt, dass alle Ihre zukünftigen Projekte diese Standardidentität tragen. Ersetzen Sie die Platzhalter durch Ihre tatsächlichen Informationen.

Name festlegen:

git config --global user.name "Ihr Vollständiger Name"

E-Mail festlegen:

Es wird dringend empfohlen, die E-Mail-Adresse zu verwenden, die mit Ihrem GitHub-/GitLab-/Bitbucket-Konto verknüpft ist, insbesondere wenn Sie SSH-Schlüssel oder Commit-Signierung verwenden.

git config --global user.email "[email protected]"

Best Practice: Verwenden Sie die genaue E-Mail-Adresse, die mit Ihrem Hosting-Anbieter verknüpft ist, um sicherzustellen, dass Beiträge auf Remote-Plattformen korrekt angezeigt werden.

2. Identität für ein bestimmtes Repository überschreiben (lokale Ebene)

Manchmal arbeiten Sie an einem Projekt, das eine bestimmte Zuordnung erfordert (z. B. Verwendung einer Arbeits-E-Mail für ein Kunden-Repository). Sie können die globalen Einstellungen nur innerhalb dieses Repositorys überschreiben.

Navigieren Sie zum Stammverzeichnis des Repositorys und führen Sie die Konfigurationsbefehle ohne das --global-Flag aus:

# Navigieren Sie zu Ihrem Projektverzeichnis
cd ~/projekte/kundenprojekt-alpha

# Legen Sie einen spezifischen Namen für dieses Repository fest
git config user.name "Arbeitsname"

# Legen Sie eine spezifische E-Mail für dieses Repository fest
git config user.email "[email protected]"

Wenn Sie in diesem Repository committen, verwendet Git diese lokalen Einstellungen anstelle der globalen.

Wie Git die Identität auswählt

Wenn Git einen Commit verarbeitet, überprüft es die Ebenen in der Reihenfolge: Lokal -> Global -> System. Die erste Einstellung, die es für user.name oder user.email findet, wird verwendet.

Konfigurieren Ihres Standard-Texteditors

Wenn Git Ihre Eingabe benötigt – z. B. beim Schreiben einer Commit-Nachricht, einer Rebase-Anweisung oder einer Notiz zur Konfliktlösung bei Merges – öffnet es Ihren konfigurierten Texteditor. Standardmäßig könnte dies ein einfacher Terminal-Editor wie vi oder vim sein, was für neue Benutzer eine Herausforderung darstellen kann.

Globale Editor-Einstellung festlegen

Sie können Git so konfigurieren, dass es Ihren bevorzugten Editor auf allen Ihren Rechnern oder Projekten mit dem --global-Flag verwendet.

VS Code als Editor verwenden

Wenn Sie Visual Studio Code bevorzugen und die Befehlszeilenintegration (code) installiert haben, setzen Sie es wie folgt:

git config --global core.editor "code --wait"

Das --wait-Flag ist entscheidend; es weist Git an, die Ausführung anzuhalten, bis Sie die in VS Code geöffnete Datei schließen, um sicherzustellen, dass die Commit-Nachricht finalisiert wird.

Sublime Text als Editor verwenden

Für Sublime Text-Benutzer:

git config --global core.editor "subl -n -w"

Nano oder Vim verwenden (falls bereits vertraut)

Wenn Sie einen einfachen Terminal-Editor bevorzugen:

# Für Nano
git config --global core.editor "nano"

# Für Vim (oft die Standardeinstellung)
git config --global core.editor "vim"

Testen Ihrer Editor-Konfiguration

Der einfachste Weg, um zu testen, ob Ihre Editor-Konfiguration funktioniert, ist das Initiieren eines Amends, das eine Nachricht erfordert, oder das Erstellen eines Commits ohne Angabe des -m-Flags:

# Erstellen Sie eine Dummy-Datei und versuchen Sie einen Commit ohne -m
touch tempfile.txt
git add tempfile.txt
git commit 
# Dies sollte Ihren neu konfigurierten Editor öffnen.

Beheben einer vorhandenen falschen Identität

Das Ändern von user.name und user.email betrifft zukünftige Commits. Es schreibt keine bereits vorhandenen Commits um. Wenn Ihr letzter Commit den falschen Autor hat und Sie ihn noch nicht gepusht haben, können Sie ihn nach dem Korrigieren der Konfiguration ändern:

git config user.name "Korrekter Name"
git config user.email "[email protected]"
git commit --amend --reset-author

Wenn der fehlerhafte Commit bereits auf einen gemeinsamen Branch gepusht wurde, seien Sie vorsichtig. Das Umschreiben veröffentlichter Geschichte kann andere stören. Für einen privaten Branch kann ein Amend und Force Push akzeptabel sein:

git push --force-with-lease

Für einen gemeinsamen Branch ist die sicherere Antwort oft, die Geschichte in Ruhe zu lassen und die Identität für zukünftige Commits zu korrigieren. Wenn viele Commits repariert werden müssen, verwenden Sie ein Tool zum Umschreiben der Geschichte nur nach Absprache mit dem Team.

Überprüfen, woher ein Wert stammt

Wenn Git sich seltsam verhält, kann git config --list zu laut sein. Verwenden Sie --show-origin, damit Git Ihnen mitteilt, welche Datei welchen Wert geliefert hat:

git config --show-origin --list

Sie könnten eine Ausgabe wie diese sehen:

datei:/Users/alex/.gitconfig    [email protected]
datei:.git/config               [email protected]

Das bedeutet, dass der repository-lokale Wert im aktuellen Repository gewinnt. Dies ist der schnellste Weg, um zu diagnostizieren: "Ich habe meine globale E-Mail geändert, aber Git verwendet immer noch die alte."

Sie können auch nach einem einzelnen Wert fragen:

git config --show-origin user.email

Ein Arbeits- und Privat-Setup, das Bestand hat

Ein häufiges Muster ist, eine persönliche globale Identität zu behalten und Arbeits-Repositorys lokal zu überschreiben:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

cd ~/arbeit/zahlungen-api
git config user.email "[email protected]"

Einige Teams bevorzugen separate Klone unter separaten Verzeichnissen. Neuere Git-Versionen unterstützen bedingte Includes, die automatisch eine Arbeitskonfiguration für Repositorys unter einem Pfad laden können:

# ~/.gitconfig
[user]
    name = Alex Rivera
    email = [email protected]

[includeIf "gitdir:~/arbeit/"]
    path = ~/.gitconfig-arbeit

# ~/.gitconfig-arbeit
[user]
    email = [email protected]

Die genauen Pfadabgleichsregeln können plattformübergreifend etwas überraschend sein, testen Sie sie daher in einem echten Repository:

cd ~/arbeit/ein-repo
git config --show-origin user.email

Editor-Probleme, die Sie vermeiden können

Die core.editor-Einstellung ist hauptsächlich dann wichtig, wenn Git eine Nachricht oder Anweisungsdatei benötigt: Merge-Commits, interaktive Rebases, Commit-Amendments und Commits ohne -m. Wenn Git Vim öffnet und Sie sich dort nicht wohlfühlen, kann es sich anfühlen, als ob der Befehl hängt.

Für VS Code ist das --wait-Flag nicht optional:

git config --global core.editor "code --wait"

Ohne --wait kann Git die Datei öffnen und sofort fortfahren, bevor Sie die Nachricht fertig geschrieben haben. Für reine Terminal-Server ist nano oft weniger überraschend:

git config --global core.editor "nano"

Sie können den Editor testen, ohne eine echte Projektänderung zu erstellen:

git commit --allow-empty

Schreiben Sie eine Testnachricht, speichern Sie und löschen Sie dann den leeren Commit, wenn Sie ihn nicht möchten:

git reset --soft HEAD~1

Commit-Signierung und Hosting-Konten

Ihre Git-E-Mail ist getrennt von der Authentifizierung. SSH-Schlüssel, persönliche Zugriffstoken und Browser-Login entscheiden, ob Sie pushen können. user.email entscheidet, welche Autor-E-Mail in das Commit-Objekt geschrieben wird.

Hosting-Anbieter gleichen Commits normalerweise per E-Mail-Adresse mit Ihrem Konto ab. Wenn Sie eine Privatsphäre-E-Mail verwenden, setzen Sie diese genaue Adresse:

git config --global user.email "[email protected]"

Wenn Ihre Organisation signierte Commits erfordert, ist die Identität nur ein Teil des Setups. Möglicherweise benötigen Sie auch user.signingkey, commit.gpgsign oder SSH-Signierungskonfiguration. Halten Sie dies getrennt vom grundlegenden Name/E-Mail-Setup, damit Sie eine Ebene nach der anderen debuggen können.

Autor, Committer und Umgebungsüberschreibungen

Git speichert sowohl einen Autor als auch einen Committer in jedem Commit. Meistens sind sie dieselbe Person. Sie unterscheiden sich, wenn jemand einen Patch von einem anderen Entwickler anwendet, Commits rebased oder einen Commit ändert, der ursprünglich von jemand anderem geschrieben wurde.

Sie können beide Felder mit anzeigen:

git log --format=fuller -1

Diese Ausgabe ist nützlich, wenn jemand sagt "Git hat die falsche E-Mail verwendet", aber das normale einzeilige Log zeigt nur den Autor. Der Committer kann anders sein, weil ein Betreuer den Patch angewendet hat oder weil ein Rebase den Commit neu erstellt hat.

Git kann die Identität auch aus Umgebungsvariablen lesen:

GIT_AUTHOR_NAME="Build Bot" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Generierte Dateien aktualisieren"

CI-Systeme verwenden manchmal dieses Muster. Es ist in Ordnung, wenn es beabsichtigt ist, aber verwirrend, wenn eine Pipeline diese Variablen in eine Entwickler-Shell oder ein lokales Skript durchsickern lässt. Wenn Git Ihre Konfiguration ignoriert, überprüfen Sie die Umgebung:

env | rg '^GIT_(AUTHOR|COMMITTER)'

Entfernen Sie versehentliche Überschreibungen vor dem Commit:

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Eine kleine Teamrichtlinie, die chaotische Geschichte verhindert

Für Teams ist die beste Git-Benutzerkonfigurationsrichtlinie normalerweise kurz:

Verwenden Sie Ihren richtigen Namen oder denselben Handle, den Ihr Team erkennt.
Verwenden Sie eine Firmen-E-Mail für Firmen-Repositorys.
Verwenden Sie eine verifizierte Hosting-Anbieter-E-Mail, damit Commits dem richtigen Konto zugeordnet werden.
Schreiben Sie keine gemeinsame Geschichte um, nur um alte Autor-Metadaten zu bereinigen, es sei denn, das Team stimmt zu.
Dokumentieren Sie den bevorzugten core.editor nur, wenn Ihre Onboarding-Skripte davon abhängen.

Sie können eine Pre-Commit- oder Pre-Push-Prüfung für E-Mail-Domänen hinzufügen, aber halten Sie sie freundlich. Ein lokaler Hook, der jeden Commit blockiert, weil jemand von einem anderen Rechner aus pairt, erzeugt Reibung. Eine serverseitige Richtlinie oder CI-Prüfung auf geschützten Branches ist normalerweise einfacher zu verwalten.

Hier ist eine einfache lokale Prüfung, die Sie manuell ausführen können, bevor Sie Arbeitscode pushen:

git config user.email
git log --format='%h %ae %s' origin/main..HEAD

Wenn ein Commit eine persönliche E-Mail auf einem Firmen-Branch zeigt, korrigieren Sie es, bevor Sie den Pull-Request öffnen. Das ist viel einfacher, als später einen gemergten Branch zu reparieren.

Fehlerbehebung bei häufigen Konfigurationsüberraschungen

Wenn git config --global user.email den richtigen Wert anzeigt, Commits aber trotzdem etwas anderes verwenden, überprüfen Sie, ob Sie sich in einem Repository mit einer lokalen Überschreibung befinden:

git config --local user.email
git config --show-origin user.email

Wenn der lokale Wert falsch ist, ersetzen Sie ihn oder entfernen Sie ihn:

git config user.email "[email protected]"
git config --unset user.email

Das Entfernen des lokalen Werts führt dazu, dass Git auf den globalen Wert zurückfällt. Das ist oft sauberer, als denselben Wert in jedem Repository zu setzen.

Wenn Git sagt Author identity unknown, bedeutet dies, dass Git keinen verwendbaren user.name und user.email aus der Konfiguration oder Umgebung finden konnte. Setzen Sie beide, nicht nur einen:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

Vermeiden Sie auf gemeinsam genutzten Servern --system, es sei denn, Sie verwalten den Rechner für alle. Eine systemweite Identität kann dazu führen, dass nicht verwandte Benutzer versehentlich als dieselbe Person committen. Build-Agenten sind die Hauptausnahme, und selbst dort ist es normalerweise besser, den CI-Arbeitsbereich oder das Dienstkonto explizit zu konfigurieren.

Kurze Checkliste

Verwenden Sie git config --global für Einstellungen, die überall gelten, wie Ihre Standardidentität und Ihren Editor.
Verwenden Sie git config (ohne Flags) innerhalb eines Repositorys, um globale Einstellungen lokal zu überschreiben.
Verwenden Sie git config --show-origin --list, wenn Sie wissen müssen, welche Datei gewinnt.
Verwenden Sie git commit --amend --reset-author nur, wenn das Umschreiben des letzten Commits angemessen ist.
Verwenden Sie --wait bei der Konfiguration grafischer Editoren, damit Git darauf wartet, dass Sie die Bearbeitung abschließen.