Einführung

Im Alltag „speichert" man ein Dokument, aber in Git heißt die entsprechende Aktion Committing. Ein Commit erfasst eine dauerhafte Momentaufnahme Ihrer gestageten Dateien und deren Änderungen in der Geschichte des Repositorys. Anders als das Drücken von Speichern in einem Editor überschreibt ein Commit nicht die vorherige Version — er fügt einen neuen Eintrag zu einer Zeitleiste hinzu, die Sie jederzeit abrufen, vergleichen oder rückgängig machen können.

Diese Seite ist eine Übersicht der Befehle, die Sie verwenden, um Änderungen lokal zu speichern und für das Teilen vorzubereiten. Jeder Abschnitt verweist auf ein eigenes Kapitel mit vollständigen Optionen und Beispielen.

Die drei Bereiche, durch die Änderungen fließen

Um das Speichern in Git zu verstehen, ist es hilfreich zu wissen, dass eine Datei gleichzeitig an drei Orten existieren kann:

• Arbeitsverzeichnis — die Dateien, die Sie auf der Festplatte bearbeiten.
• Staging-Bereich (auch Index genannt) — eine Zwischenzone, in der Sie genau das zusammenstellen, was der nächste Commit enthalten wird.
• Repository — die gespeicherte Historie, im versteckten .git-Ordner gespeichert.

Änderungen zu speichern bedeutet, sie vom Arbeitsverzeichnis über den Staging-Bereich in das Repository zu verschieben:

edit files        # changes live in the working directory
git add <file>    # move them into the staging area
git commit        # record them permanently in the repository

Der zweistufige Ablauf mit add und dann commit ist bewusst so gestaltet: Er ermöglicht es Ihnen, nur einen Teil Ihrer Arbeit zu committen und den Rest für später aufzuheben, wodurch fokussierte, aussagekräftige Commits entstehen.

git add

Der Befehl git add verschiebt Änderungen aus dem Arbeitsverzeichnis in den Staging-Bereich. Er teilt Git mit, welche Aktualisierungen in den nächsten Commit aufgenommen werden sollen. Allein erzeugt git add nichts Dauerhaftes — Sie müssen es mit git commit abschließen.

git add index.html      # stage a single file
git add src/            # stage everything under a directory
git add .               # stage all changes in the current directory tree

Führen Sie git status jederzeit aus, um zu sehen, welche Dateien gestaget, geändert oder nicht verfolgt sind.

git commit

Der Befehl git commit speichert alle aktuell gestageten Änderungen als neuen Snapshot im Repository. Jeder Commit ist ein dauerhafter Punkt in der Geschichte, zu dem Sie zurückkehren können. Da nur gestagete Änderungen erfasst werden, muss git add zuerst ausgeführt werden.

git commit -m "Add contact form validation"

Verwenden Sie eine kurze, beschreibende Nachricht im Imperativ („Add", „Fix", „Update"). Wenn Sie -m weglassen, öffnet Git den konfigurierten Editor, sodass Sie eine längere Nachricht schreiben können.

git diff

Der Befehl git diff vergleicht verschiedene Zustände Ihres Projekts, damit Sie genau überprüfen können, was Sie gerade speichern möchten. Standardmäßig zeigt git diff nicht gestagete Änderungen — den Unterschied zwischen Ihrem Arbeitsverzeichnis und dem Staging-Bereich. Fügen Sie --staged hinzu, um zu sehen, was bereits gestaget und bereit zum Committen ist.

git diff             # working directory vs. staging area (not yet staged)
git diff --staged    # staging area vs. last commit (about to be committed)

Einen Diff vor dem Committen zu überprüfen ist der beste Weg, um zu vermeiden, Debug-Code oder versehentliche Bearbeitungen zu speichern.

git stash

Der Befehl git stash legt nicht committete Änderungen vorübergehend beiseite, sodass Ihr Arbeitsverzeichnis sauber wird — nützlich, wenn Sie die Aufgabe wechseln oder Aktualisierungen abrufen müssen, ohne halbfertige Arbeit zu committen. Die Änderungen werden auf einem Stapel gespeichert, den Sie später erneut anwenden können.

git stash        # set aside current changes and revert to a clean tree
git stash pop    # re-apply the most recent stash and remove it from the stack

.gitignore

Einige Dateien sollten niemals committed werden — Build-Ausgaben, Abhängigkeiten, Geheimnisse oder OS-Metadaten. Git liest eine Datei namens .gitignore, um zu entscheiden, welche Pfade übersprungen werden sollen. Es gibt keinen Befehl git ignore; Sie erstellen und committen diese Datei selbst und listen Muster auf, die Git von der Verfolgung ausschließen soll:

# Dependencies
node_modules/
# OS files
.DS_Store
Thumbs.db
# Secrets
.env

Beachten Sie, dass .gitignore nur Dateien betrifft, die Git noch nicht verfolgt. Um die Verfolgung einer Datei zu beenden, die vor dem Ignorieren committed wurde, verwenden Sie git rm --cached.

Typischer Arbeitsablauf

Eine Standardabfolge zum Speichern und Teilen von Änderungen sieht so aus:

git status                          # see what changed
git add .                           # stage the changes
git diff --staged                   # review what is about to be committed
git commit -m "Implement feature"   # save a permanent snapshot
git push origin main                # upload commits to the remote

Die ersten vier Schritte speichern Ihre Arbeit lokal; git push teilt sie mit einem Remote-Server wie GitHub.

Rückgängig machen vor dem Speichern

Wenn Sie etwas versehentlich gestaget haben, können Sie es wieder aus dem Staging-Bereich entfernen, ohne Ihre Bearbeitungen zu verlieren:

git restore --staged <file>    # unstage, keep the changes in the working directory
git restore <file>             # discard working-directory changes (cannot be undone)

Weitere Möglichkeiten, Änderungen nach einem Commit rückgängig zu machen, finden Sie unter git reset.

Übung