Git-Tutorial: Git installieren und richtig konfigurieren

Dieses Kapitel installiert Git, setzt die drei Einstellungen, ohne die dein erster Commit abgelehnt wird, und richtet die Authentifizierung bei GitHub oder GitLab ein. Rechne mit einer knappen Viertelstunde, den SSH-Schlüssel eingeschlossen.

Wenn du direkt hier einsteigst: der Unterschied zwischen Git und GitHub und der Aufbau des Lernwegs stehen in der Einführung zum Tutorial.

Git installieren

Unter macOS und Linux ist Git wahrscheinlich schon vorhanden. Prüf das, bevor du irgendetwas installierst:

git --version

Antwortet der Befehl mit einer Versionsnummer, ist Git installiert und du kannst direkt zur Konfiguration springen. Meldet er, dass der Befehl nicht gefunden wurde, folge dem Abschnitt zu deinem System.

Windows

Am einfachsten geht es mit dem Paketmanager, der in Windows schon steckt:

winget install --id Git.Git -e --source winget

Alternativ lädst du den Installer von git-scm.com/install/windows und lässt die Standardoptionen stehen. Die zum Zeitpunkt dieser Prüfung aktuelle Version ist Git for Windows 2.55.0(5) vom 20. August 2026. Die Installation bringt Git Bash mit, ein Terminal, das eine Unix-Umgebung nachbildet. Nimm es statt der Eingabeaufforderung: alle Befehle aus diesem Tutorial funktionieren dort unverändert.

macOS

Git kommt mit den Command Line Tools von Xcode. Beim ersten Aufruf von git bietet macOS die Installation an, du kannst sie auch erzwingen:

xcode-select --install

Diese Version ist zuverlässig, hinkt der offiziellen aber oft ein paar Monate hinterher. Wenn du aktuell bleiben willst, nimm Homebrew:

brew install git

Linux

Nimm den Paketmanager deiner Distribution.

# Debian, Ubuntu und Derivate
sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky
sudo dnf install git

# Arch
sudo pacman -S git

# Alpine
sudo apk add git

Die installierte Version hängt von Ihrer Distribution ab, und der Abstand ist manchmal groß. Die am 7. September 2026 erhobenen Versionen stehen im Abschnitt „Gemessenes Ergebnis“ am Ende dieses Kapitels. Ubuntu 24.04 liefert Git 2.43 von Ende 2023: Das reicht für alles in diesem Tutorial bei Weitem, denn die neuesten von uns verwendeten Befehle stammen aus Git 2.23.

Sich zu erkennen geben: Name und E-Mail-Adresse

Git schreibt den Autor jedes Commits in die Historie. Solange du ihm nicht gesagt hast, wer du bist, speichert er gar nichts:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@23d1d26b6831.(none)')

Setz also zuerst die beiden Werte:

git config --global user.name "Damien Flandrin"
git config --global user.email "dam@example.com"

Die Option --global schreibt in deine persönliche Datei und gilt für alle Projekte. Ohne sie betrifft die Einstellung nur das aktuelle Repository, was praktisch ist, wenn du in manchen Projekten eine dienstliche und in anderen eine private Adresse verwendest.

Nimm eine Adresse, die öffentlich sein darf: sie steht in der Historie, und die Historie geht an jeden, der das Projekt klont. GitHub bietet eine Ersatzadresse unter @users.noreply.github.com an, wenn du deine eigene lieber nicht preisgibst.

Den Namen des Standard-Branch festlegen

Zu keinem anderen Punkt kursieren mehr Falschinformationen. Oft liest man, Git lege inzwischen einen Branch main an. Das stimmt nicht. Das hier macht git init mit Git 2.55, der aktuellen Version im September 2026:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /root/a1/.git/

Der Branch heißt also weiterhin master, und Git kündigt selbst an, dass der Standard erst ab Version 3.0 auf main wechselt. Geändert haben sich die Hoster: GitHub legt neue Repositories seit Oktober 2020 mit einem Branch main an, GitLab seit Version 14. Daher der ständige Versatz zwischen dem, was deine Maschine tut, und dem, was der Server tut.

Klär die Sache ein für alle Mal:

git config --global init.defaultBranch main

Die Meldung verschwindet, und die danach angelegten Repositories starten auf main. Achtung: die Einstellung gilt nur für neue Repositories. Für ein bestehendes Repository, dessen Branch master heißt:

git branch -m master main

Die eigene Konfiguration prüfen

Drei Befehle reichen, um zu sehen, wo du stehst:

git config --global --list                # was gesetzt ist
git config --global --list --show-origin  # und in welcher Datei
git config --global --edit                # die Datei öffnen

Die persönliche Konfiguration ist eine einfache Textdatei, ~/.gitconfig, die du direkt lesen und ändern kannst:

[user]
	name = Damien Flandrin
	email = dam@example.com
[init]
	defaultBranch = main

Zwei weitere Einstellungen setzt du am besten gleich mit. Zuerst den Editor, den Git für Commit-Nachrichten öffnet, sonst landest du früher oder später in Vim, ohne wieder herauszufinden:

git config --global core.editor "code --wait"   # Visual Studio Code
git config --global core.editor "nano"          # oder ein beliebiger Terminal-Editor

Und dann das Verhalten von git pull, das wir im Kapitel über Branches genauer ansehen:

git config --global pull.rebase true

Sich bei GitHub oder GitLab authentifizieren

Hier ist eine Klarstellung nötig, weil dieser Punkt Einsteiger viel Zeit kostet. Dein GitHub-Passwort nützt dir für Git nichts mehr. GitHub akzeptiert seit dem 13. August 2021 keine Kontopasswörter mehr für Git-Operationen. Das antwortet der Server, wenn du es trotzdem versuchst:

Cloning into 'depot-prive'...
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/damienflandrin/depot-prive.git/'

Es bleiben zwei gültige Verfahren: der SSH-Schlüssel oder das Personal Access Token. Der SSH-Schlüssel ist in fünf Minuten eingerichtet und meldet sich danach nie wieder. Ihn empfehlen wir.

Einen SSH-Schlüssel erzeugen

ssh-keygen -t ed25519 -C "dam@example.com"

Bestätige den vorgeschlagenen Pfad. Die Passphrase ist optional, aber empfehlenswert: sie schützt den Schlüssel, falls deine Maschine kompromittiert wird.

Generating public/private ed25519 key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:s5YjDRbNgv3/o8SvEFh4A6hzpWddSsquX0l0k4aUptw dam@example.com

Es sind zwei Dateien entstanden. id_ed25519 ist der private Schlüssel: er verlässt deine Maschine nie, wird nirgendwohin kopiert und in kein Formular eingefügt. id_ed25519.pub ist der öffentliche Schlüssel, den du dem Server anvertraust.

Gib den öffentlichen Schlüssel aus und kopiere die komplette Zeile:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINjiBkboRdOPXk2UWn3UUMSv2qr8G9cGvzKsTd+ZyYCa dam@example.com

Füge sie dann bei GitHub unter Settings > SSH and GPG keys > New SSH key ein, bei GitLab unter Einstellungen > SSH-Schlüssel.

Prüfen, ob der Schlüssel funktioniert

ssh -T git@github.com

Bei der ersten Verbindung musst du den Fingerabdruck des Servers bestätigen. Der von GitHub lautet für Ed25519-Schlüssel SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU, vergleiche ihn mit dem von GitHub veröffentlichten, bevor du mit yes antwortest. Passt alles, antwortet GitHub mit einer Begrüßung, die deinen Benutzernamen nennt und darauf hinweist, dass Shell-Zugriff nicht erlaubt ist, was normal ist. Bekommst du stattdessen:

git@github.com: Permission denied (publickey).

dann wurde der öffentliche Schlüssel nicht in deinem Konto hinterlegt, oder du hast versehentlich den privaten eingefügt.

Die Alternative: das Personal Access Token

Wenn SSH in deinem Netz blockiert ist oder du in einem CI-Skript arbeitest, nimm ein Personal Access Token. Bei GitHub legst du es unter Settings > Developer settings > Personal access tokens an, am besten als fein granuliertes Token (fine-grained), das den Zugriff auf ein bestimmtes Repository beschränkt und von selbst abläuft. Bei GitLab findest du das Gegenstück unter Einstellungen > Zugriffstoken.

Das Token tritt an die Stelle des Passworts, wenn Git danach fragt. Damit du es nicht bei jedem Befehl neu eintippst, aktivierst du einen Credential Helper:

git config --global credential.helper store    # einfach, aber das Token steht im Klartext
git config --global credential.helper osxkeychain  # macOS, Speicherung im Schlüsselbund

Unter Windows ist der Git Credential Manager mit Git for Windows bereits installiert und aktiv.

Behandle ein Token genau wie ein Passwort: es gehört nicht in ein Repository, nicht in eine versionierte Konfigurationsdatei und nicht in eine URL, die du weitergibst.

Dein Rechner ist bereit. Das nächste Kapitel legt ein Repository bei GitHub oder GitLab an und verbindet es mit einem Ordner auf deiner Maschine.

Gemessenes Ergebnis

Von der Paketverwaltung installierte Git-Version auf dem offiziellen Image jeder Distribution, erhoben am 7. September 2026:

Alle genügen: Der neueste in diesem Tutorial verwendete Befehl, git switch, stammt aus Git 2.23.