Git-Verhalten anpassen: Konfiguration, Aliase und wichtige Dateien

Die Anpassung des Git-Verhaltens hilft Ihnen, die tägliche Versionskontrolle schneller, sicherer und vorhersehbarer zu gestalten. Mit der richtigen Git-Konfiguration, Aliasen und wichtigen Dateien kann Ihr lokaler Workflow dem entsprechen, wie Ihr Team tatsächlich Software entwickelt.

Das Ziel ist nicht, eine clevere Einrichtung zu schaffen, die niemand sonst versteht. Das Ziel ist, Reibung bei alltäglichen Aufgaben zu vermeiden, während Ihre Repositorys einfach zu überprüfen und zu unterstützen bleiben.

Wie die Git-Konfiguration funktioniert

Git liest Einstellungen von mehreren Stellen, und die nähere Einstellung gewinnt. Das ist wichtig, wenn Sie debuggen, warum Git den falschen Namen, Editor, Merge-Tool, Zeilenenden oder Signierverhalten verwendet.

Die drei Hauptkonfigurationsbereiche sind:

• System: gilt für jeden Benutzer auf dem Rechner.
• Global: gilt für Ihr Benutzerkonto.
• Lokal: gilt nur für das aktuelle Repository.

Sie arbeiten normalerweise mit globalen und lokalen Einstellungen. Globale Einstellungen sind gut für Ihre Identität, den Standardeditor und allgemeine Aliase. Lokale Einstellungen sind besser für repository-spezifisches Verhalten, wie eine andere E-Mail-Adresse für Arbeitsprojekte.

Verwenden Sie diese Befehle, um zu überprüfen, woher eine Einstellung kommt:

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

Zum Beispiel könnten Sie Ihre persönliche E-Mail global verwenden:

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

Dann überschreiben Sie innerhalb eines Arbeits-Repositorys nur die E-Mail:

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

Dies vermeidet versehentliches Committen in einem Firmen-Repository mit einer persönlichen Identität. Es macht die Commit-Historie auch sauberer für Compliance, Eigentumsverhältnisse und Code-Reviews.

Wenn Sie eine tiefergehende Auffrischung zu Identitätseinstellungen wünschen, lesen Sie Git-Benutzerkonfiguration meistern.

Nützliche Einstellungen, die Sie zuerst anpassen sollten

Beginnen Sie mit Einstellungen, die Klarheit verbessern und kleine Fehler verhindern. Sie brauchen keine riesige Konfigurationsdatei, um echten Wert zu erzielen.

Eine gute Grundlage umfasst Ihren Standard-Branchnamen:

git config --global init.defaultBranch main

Legen Sie Ihren bevorzugten Editor fest, damit Git Commit-Nachrichten, Rebase-Pläne und Merge-Notizen in einem Tool öffnen kann, das Sie tatsächlich verwenden:

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

Wenn Sie mit macOS, Linux und Windows arbeiten, verdienen Zeilenenden Aufmerksamkeit. Viele Teams entscheiden sich dafür, Zeilenenden im Repository zu normalisieren und jedem Entwickler die Anzeige im Editor zu überlassen. Eine häufige Windows-Einstellung ist:

git config --global core.autocrlf true

Unter macOS oder Linux verwenden Teams oft:

git config --global core.autocrlf input

Ändern Sie Zeilenenden-Einstellungen nicht leichtfertig in einem bestehenden Repository. Wenn Sie einen riesigen Diff sehen, bei dem jede Zeile geändert erscheint, stoppen Sie und überprüfen Sie .gitattributes, bevor Sie committen.

Sie können Gits Ausgabe auch lesbarer machen:

git config --global color.ui auto
git config --global column.ui auto
git config --global branch.sort -committerdate
git config --global tag.sort version:refname

Für das Ziehen von Änderungen wählen Sie das Verhalten, das Ihr Team erwartet:

git config --global pull.rebase false

oder:

git config --global pull.rebase true

Keine Option ist universell richtig. Merge-basierte Pulls bewahren Merge-Commits. Rebase-basierte Pulls bewahren eine lineare lokale Historie. Wichtig ist, bewusst zu wählen und Teamerwartungen zu dokumentieren.

Git-Aliase erstellen, die Zeit sparen

Git-Aliase verwandeln lange Befehle in kurze, einprägsame Abkürzungen. Sie sind besonders nützlich für Befehle, die Sie mehrmals täglich ausführen.

Hier sind praktische Aliase, die lesbar bleiben:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"

Danach gibt git st Ihnen den Status und git unstage file.txt entfernt eine Datei aus der Staging-Area, ohne Ihre Arbeitskopie zu berühren.

Log-Aliase sind der Bereich, in dem viele Teams den größten Nutzen ziehen:

git config --global alias.lg "log --oneline --decorate --graph --all"

Jetzt können Sie ausführen:

git lg

Dies gibt Ihnen einen kompakten Graphen von Branches, Tags und Commits. Es ist nützlich vor Rebasing, Merging oder dem Aufräumen lokaler Branches.

Halten Sie Aliase langweilig genug, dass ein Teammitglied erraten kann, was sie tun. Ein Alias wie git save könnte je nach Ersteller Commit, Stash oder etwas anderes bedeuten. Ein Alias wie git unstage ist offensichtlich.

Sie können Ihre Aliase überprüfen mit:

git config --global --get-regexp '^alias\.'

Für weitere Beispiele lesen Sie benutzerdefinierte Git-Aliase erstellen.

Wichtige Git-Dateien, die Sie kennen sollten

Das Git-Verhalten wird nicht nur durch git config gesteuert. Mehrere Repository-Dateien beeinflussen, was verfolgt, ignoriert, normalisiert und geschützt wird.

Die häufigste Datei ist .gitignore. Sie teilt Git mit, welche unverfolgten Dateien ignoriert werden sollen. Typische Einträge umfassen Build-Ausgaben, lokale Umgebungsdateien, Editor-Ordner und Abhängigkeits-Caches:

node_modules/
dist/
.env
.DS_Store

Seien Sie vorsichtig mit breiten Mustern. Das Ignorieren von *.json könnte generierte Dateien verstecken, aber auch wichtige Konfiguration. Ignorieren Sie wenn möglich spezifische Verzeichnisse oder Dateinamen.

Die Datei .gitattributes steuert, wie Git Dateitypen behandelt. Sie ist nützlich für Zeilenenden, generierte Dateien, Linguist-Verhalten und Merge-Strategien:

* text=auto
*.sh text eol=lf
*.bat text eol=crlf

Dies ist besonders hilfreich in Teams, die verschiedene Betriebssysteme verwenden. Es reduziert laute Diffs und verhindert, dass Skripte aufgrund falscher Zeilenenden brechen.

Die Datei .git/config speichert die lokale Repository-Konfiguration. Sie bearbeiten sie normalerweise mit git config --local, aber das Lesen kann Ihnen helfen, Remotes, Branch-Tracking und repository-spezifische Optionen zu debuggen.

Git-Hooks befinden sich unter .git/hooks/. Sie können Skripte vor Commits, Pushes, Merges und anderen Ereignissen ausführen. Standardmäßig sind Hooks lokal und werden nicht als aktive Skripte committed. Teams, die auf Hooks angewiesen sind, verwenden oft ein Setup-Skript oder einen Hook-Manager, um sie konsistent zu installieren.

Wann Sie um Hilfe bitten sollten

Die meisten Git-Konfigurationsänderungen sind sicher, aber einige können ein Team stören, wenn sie ohne Kontext angewendet werden. Fragen Sie einen Senior Engineer, DevOps Engineer oder Repository-Besitzer, bevor Sie Zeilenenden-Regeln, Merge-Treiber, Signieranforderungen oder gemeinsames Hook-Verhalten ändern.

Sie sollten auch Hilfe holen, wenn Commits mit der falschen Identität in einem geschützten Repository erscheinen. Das Korrigieren von Autor-Metadaten nach dem Pushen von Code kann eine Umschreibung der Historie erfordern, was alle betrifft, die diesen Branch verwenden.

Wenn Git sich plötzlich anders verhält, beginnen Sie mit git config --list --show-origin. Dieser eine Befehl erklärt das Rätsel oft schneller als Raten.

Durchdachte Anpassung lässt Git weniger repetitiv wirken, ohne zu verbergen, was passiert. Halten Sie Ihre Aliase klar, dokumentieren Sie Repository-Regeln und verwenden Sie lokale Einstellungen, wenn ein Projekt ein anderes Verhalten als der Rest Ihres Rechners benötigt.