Git-Befehle für Einsteiger: Der sichere Workflow fürs erste Projekt

Dein Coding-Agent hat gerade zwölf Dateien verändert. Die App läuft noch, aber du weißt nicht genau, was passiert ist. Jetzt wäre ein Knopf mit der Aufschrift „Diesen funktionierenden Stand bitte merken“ ziemlich praktisch.

Genau dafür ist Git da. Git speichert nachvollziehbare Zwischenstände deines Projekts. Du kannst Änderungen prüfen, gezielt zusammenfassen und später sehen, wann warum etwas geändert wurde. Gerade beim Vibe Coding ist das keine Kür: Je schneller ein Agent Code erzeugt, desto wichtiger wird ein verlässlicher Weg zurück.

Dieser Artikel zeigt dir einen einfachen Arbeitsablauf mit den wichtigsten Git-Befehlen – ohne dass du gleich Branch-Strategien, Merge-Konflikte und Pull Requests meistern musst.

Git und GitHub sind nicht dasselbe

Git ist die Versionsverwaltung auf deinem Rechner. Ein Projektordner, in dem Git Änderungen verfolgt, heißt Repository. Du kannst Git vollständig lokal verwenden, ohne Konto und ohne Internetverbindung.

GitHub ist dagegen ein Onlinedienst, auf dem Git-Repositories gespeichert und gemeinsam bearbeitet werden können. Alternativen sind zum Beispiel GitLab, Bitbucket oder ein eigener Git-Server. Ein entferntes Repository wird häufig Remote genannt.

Das mentale Modell besteht für den Anfang aus vier Stationen:

1. Arbeitsverzeichnis: Hier bearbeitest du deine normalen Projektdateien.
2. Staging Area: Hier stellst du gezielt zusammen, was in den nächsten Zwischenstand gehört.
3. Lokales Repository: Hier speichert Git deine bestätigten Zwischenstände, die Commits.
4. Remote Repository: Hierhin kannst du Commits später als externes Backup oder für die Zusammenarbeit übertragen.

Ein Commit ist also nicht einfach „Speichern“. Deine Dateien sind bereits gespeichert, sobald Editor oder Agent sie auf die Festplatte geschrieben haben. Ein Commit ist ein benannter Schnappschuss ausgewählter Änderungen.

Git prüfen und einmalig einrichten

Wenn du bereits die Vibe-Coding-Setup-Anleitung umgesetzt hast, arbeitest du wahrscheinlich schon im Terminal und hast Homebrew installiert. Prüfe zuerst, ob Git verfügbar ist:

git --version

Erscheint eine Versionsnummer, kannst du weitermachen. Falls der Befehl nicht gefunden wird, nutze die offizielle Installationsanleitung von Git für dein Betriebssystem. Auf einem Mac mit Homebrew kannst du Git beispielsweise so installieren:

brew install git

Jeder Commit enthält einen Namen und eine E-Mail-Adresse. Diese Angaben identifizieren den Autor des Commits; sie sind keine Zugangsdaten. Lege sie einmalig fest:

git config --global user.name "Vorname Nachname"
git config --global user.email "du@example.com"
git config --global init.defaultBranch main

--global bedeutet, dass die Einstellung für alle Repositories deines Benutzerkontos gilt. Wenn du für ein berufliches Projekt eine andere Adresse verwenden möchtest, kannst du im betreffenden Projekt dieselben Befehle ohne --global ausführen. Die lokale Einstellung hat dort Vorrang.

Prüfen kannst du die Werte mit:

git config --global --get user.name
git config --global --get user.email

Verwende eine Adresse, die du auch öffentlich mit deinen Commits verbinden möchtest. Veröffentlichst du das Repository später auf GitHub oder einer ähnlichen Plattform, können die Commit-Metadaten sichtbar werden.

Ein bestehendes Projekt unter Versionskontrolle stellen

Wechsle zuerst in deinen Projektordner. pwd zeigt dir zur Sicherheit, wo du gerade bist:

cd ~/code/mein-erstes-tool
pwd

Initialisiere dort ein Repository:

git init

Git legt einen versteckten Ordner namens .git an. Darin befinden sich die Versionshistorie und die Repository-Konfiguration. Deine eigentlichen Projektdateien werden durch git init weder verschoben noch hochgeladen.

Der wichtigste Befehl direkt danach ist:

git status

git status beantwortet drei Fragen: Auf welchem Branch befindest du dich? Welche Dateien wurden verändert? Welche Änderungen sind bereits für den nächsten Commit vorgemerkt? Führe den Befehl ruhig nach jedem Schritt erneut aus. Er verändert nichts.

Vor dem ersten Commit: Dateien bewusst ausschließen

Nicht jede Datei eines Projekts gehört in Git. Abhängigkeiten lassen sich oft neu installieren, Build-Ausgaben neu erzeugen und Betriebssystemdateien sind für andere Rechner nutzlos. Zugangsdaten dürfen erst recht nicht im Repository landen.

Lege deshalb im Projektordner eine Datei namens .gitignore an. Für ein einfaches Node.js-Projekt könnte sie so aussehen:

node_modules/
dist/
.DS_Store
.env
.env.*

Das ist ein Muster, keine universelle Liste. Welche Verzeichnisse ignoriert werden sollten, hängt von der verwendeten Sprache und den Werkzeugen ab. Prüfe mit git status, ob Git nur die Dateien anzeigt, die wirklich zum Projekt gehören.

Wichtig: .gitignore wirkt nicht rückwirkend auf Dateien, die bereits in einem Commit gespeichert wurden. Wenn eine .env-Datei mit einem echten API-Schlüssel versehentlich veröffentlicht wurde, reicht es nicht, sie nachträglich zu ignorieren. Der Schlüssel muss als offengelegt behandelt und beim Anbieter ersetzt werden.

Der Kern-Workflow: prüfen, auswählen, prüfen, committen

Für den Alltag brauchst du zunächst nur fünf Befehle:

git status
git diff
git add DATEI
git diff --staged
git commit -m "Kurze Beschreibung"

Entscheidend ist die Reihenfolge. Gehen wir sie an einer kleinen Änderung durch.

1. Änderungen mit git status überblicken

Nach der Arbeit an deinem Projekt startest du immer hier:

git status

Neue Dateien erscheinen als untracked. Bereits bekannte, aber veränderte Dateien erscheinen als modified. Git beobachtet den Projektordner, nimmt neue Dateien aber nicht automatisch in einen Commit auf.

Die kompakte Variante eignet sich später für einen schnellen Überblick:

git status --short

Ein ?? markiert eine neue, noch nicht verfolgte Datei. M steht für eine veränderte Datei, A für eine neu zur Staging Area hinzugefügte Datei.

2. Inhaltliche Änderungen mit git diff lesen

git status zeigt Dateinamen. git diff zeigt die tatsächlich geänderten Zeilen:

git diff

Zeilen mit einem Minus wurden entfernt, Zeilen mit einem Plus ergänzt. Das bedeutet nicht, dass Git etwas löscht oder hinzufügt – der Befehl zeigt nur den Unterschied zwischen Arbeitsverzeichnis und Staging Area.

Prüfe nicht nur, ob die gewünschte Funktion auftaucht. Suche auch nach unbeabsichtigten Änderungen: entfernte Validierungen, fest eingetragene Zugangsdaten, große generierte Dateien oder Umbauten, die nichts mit der Aufgabe zu tun haben.

3. Änderungen mit git add auswählen

Mit git add legst du fest, was in den nächsten Commit aufgenommen werden soll:

git add src/app.js
git add README.md

Die Dateien befinden sich danach in der Staging Area. Das Wort „add“ ist etwas irreführend: Der Befehl merkt auch Änderungen und Löschungen bereits bekannter Dateien für den nächsten Commit vor.

Du wirst häufig git add . sehen. Der Befehl nimmt alle passenden Änderungen unterhalb des aktuellen Ordners auf. Das ist bequem, kann aber auch Debug-Dateien oder unabhängige Änderungen erwischen. Gerade am Anfang und nach größeren Agentenläufen ist es sicherer, Dateien einzeln hinzuzufügen.

4. Den geplanten Commit mit git diff --staged prüfen

Jetzt folgt die wichtigste Kontrolle:

git diff --staged

git diff ohne Zusatz zeigt noch nicht vorgemerkte Änderungen. git diff --staged zeigt genau das, was der nächste Commit enthalten wird. Wenn hier eine Änderung fehlt, musst du sie noch mit git add aufnehmen. Wenn etwas zu viel enthalten ist, entfernst du es wieder aus der Staging Area.

5. Mit git commit einen Zwischenstand anlegen

Wenn der Stand funktioniert und der staged Diff zusammenpasst, erstellst du den Commit:

git commit -m "CSV-Export für gefilterte Zeilen ergänzen"

Eine gute Commit-Nachricht erklärt knapp, was sich fachlich geändert hat. „Update“, „Änderungen“ oder „Agent fertig“ helfen dir in zwei Monaten kaum weiter.

Ein Commit sollte eine zusammenhängende Änderung enthalten. Neue Exportfunktion und korrigierter Tippfehler dürfen getrennte Commits sein. So bleibt die Historie verständlich und einzelne Änderungen lassen sich später leichter untersuchen.

Die Historie lesen

Nach dem ersten Commit zeigt dir dieser Befehl die Historie kompakt an:

git log --oneline

Jede Zeile beginnt mit einer verkürzten Commit-ID, gefolgt von der Nachricht. Für die Details des jüngsten Commits verwendest du:

git show

Oder du untersuchst einen bestimmten Commit:

git show COMMIT-ID

Die Commit-ID musst du normalerweise nicht vollständig tippen. Ein eindeutiger Anfang aus git log --oneline reicht.

Zwei häufige Fehler sicher korrigieren

Git kann viel rückgängig machen. Manche Befehle verwerfen dabei aber lokale Arbeit. Prüfe deshalb zuerst immer git status und lies den vorgeschlagenen Befehl vollständig.

Eine Datei versehentlich gestaged

Die Änderung soll erhalten bleiben, aber noch nicht in den nächsten Commit? Dann nimm sie aus der Staging Area:

git restore --staged src/app.js

Die Datei bleibt verändert im Arbeitsverzeichnis. Nur die Vormerkung für den nächsten Commit wird entfernt.

Eine lokale Änderung wirklich verwerfen

Wenn du die nicht committeten Änderungen an einer bereits von Git verfolgten Datei sicher nicht mehr brauchst:

git restore src/app.js

Dieser Befehl überschreibt die lokale Datei mit dem Stand aus der Staging Area. Die verworfenen Änderungen sind anschließend möglicherweise nicht über Git wiederherstellbar. Nutze ihn nicht als Experiment und übergib einem Coding-Agenten keine pauschale Anweisung wie „Setze alles zurück“, solange du den aktuellen Status nicht geprüft hast.

Ist der Fehler bereits committed, lege als Einsteiger besser keinen komplizierten Reset auf eigene Faust hin. Ein zusätzlicher Korrektur-Commit ist meist leichter nachvollziehbar. Für gemeinsam genutzte Historien gibt es außerdem git revert; dieser Workflow verdient aber eine eigene Erklärung.

Git im Alltag mit einem Coding-Agenten

Ein Coding-Agent kann Git-Befehle ausführen, aber er sollte nicht allein entscheiden, was ein sinnvoller Zwischenstand ist. Ein robuster Ablauf sieht so aus:

1. Beginne eine klar abgegrenzte Aufgabe.
2. Lass den Agenten die Änderung umsetzen und passende Tests ausführen.
3. Prüfe selbst git status und git diff.
4. Stage nur die Dateien, die zur Aufgabe gehören.
5. Kontrolliere git diff --staged.
6. Committe einen funktionierenden, verständlichen Stand.

Ein hilfreicher Prompt dafür:

Prüfe den aktuellen Git-Status und erkläre mir die Änderungen
dateiweise in einfachen Worten.

Verändere dabei keine Dateien und führe noch keinen Git-Befehl aus,
der den Zustand des Repositories ändert.

Nenne mir anschließend:
1. Änderungen, die zur aktuellen Aufgabe gehören.
2. Möglicherweise unbeabsichtigte Änderungen.
3. Dateien, die Secrets oder generierte Inhalte enthalten könnten.
4. Einen Vorschlag für eine präzise Commit-Nachricht.

Das ist bewusst ein read-only Prüfschritt. Erst wenn du den Umfang verstanden hast, lässt du Dateien stagen oder erstellst den Commit.

Wann clone, pull und push dazukommen

Sobald dein Repository auf GitHub oder einem anderen Server liegt, begegnen dir drei weitere Befehle:

• git clone URL lädt ein bestehendes Repository samt Historie auf deinen Rechner.
• git pull holt Änderungen vom Remote und integriert sie in deinen aktuellen Branch.
• git push überträgt deine lokalen Commits zum Remote.

Für ein neues lokales Repository verbindest du zunächst die Adresse des leeren Remote-Repositories:

git remote add origin REPOSITORY-URL
git push -u origin main

origin ist nur der übliche Kurzname für dieses Remote. Die konkrete URL und die Anmeldung hängen vom gewählten Anbieter ab. Kopiere Zugangstoken niemals in den Code oder in eine Remote-URL, die du weitergibst.

Ein Remote ist nützlich, aber kein vollständiges Backup-Konzept für das gesamte Projektumfeld. Nicht versionierte Dateien, lokale Datenbanken, .env-Dateien und andere ignorierte Inhalte werden durch git push nicht gesichert.

Die zehn Git-Befehle für den Anfang

Du musst Git nicht auswendig lernen. Diese kleine Liste reicht für den ersten belastbaren Workflow:

git --version           # Installation prüfen
git init                # Repository im aktuellen Ordner anlegen
git status              # Zustand und geänderte Dateien anzeigen
git diff                # Noch nicht gestagte Änderungen lesen
git add DATEI           # Änderung für den nächsten Commit vormerken
git diff --staged       # Inhalt des geplanten Commits prüfen
git commit -m "..."     # Commit erstellen
git log --oneline       # Historie kompakt anzeigen
git restore --staged DATEI  # Datei aus der Staging Area nehmen
git push                # Lokale Commits zum eingerichteten Remote übertragen

Wenn du bei einem Befehl unsicher bist, zeigt Git selbst Hilfe an:

git help status
git help commit

Auch die offizielle Git-Dokumentation und das frei verfügbare Kapitel „Recording Changes to the Repository“ erklären den grundlegenden Zyklus aus Ändern, Stagen und Committen ausführlich.

Häufige Fragen

Muss ich GitHub nutzen, um mit Git zu arbeiten?

Nein. git init, git status, git add, git commit und die lokale Historie funktionieren ohne GitHub und ohne Internet. Ein Remote wird erst für externes Sichern, Teilen oder Zusammenarbeit benötigt.

Speichert git add meine Änderung dauerhaft?

Nein. git add nimmt den aktuellen Inhalt nur in die Staging Area auf. Erst git commit erzeugt einen dauerhaften Eintrag in der lokalen Git-Historie.

Ist ein Commit automatisch ein Backup?

Ein lokaler Commit schützt dich vor vielen Fehlern im Projekt, aber nicht vor Defekt oder Verlust des Rechners. Dafür brauchst du zusätzlich ein Remote oder eine andere Backup-Lösung. Ignorierte und nicht committete Dateien sind darin nicht enthalten.

Wie oft sollte ich committen?

Immer dann, wenn eine kleine, zusammenhängende Änderung funktioniert und verständlich benannt werden kann. Ein Commit nach jeder einzelnen Tastatureingabe ist zu kleinteilig; ein einziger Commit nach einem mehrtägigen Komplettumbau ist meist zu groß.

Soll mein Coding-Agent automatisch committen?

Für den Einstieg besser nur nach deiner ausdrücklichen Freigabe. Lass den Agenten Status, Diff und Tests vorbereiten, kontrolliere den staged Diff selbst und entscheide dann über Commit-Nachricht und Umfang.

Fazit

Git wird übersichtlich, sobald du es nicht als Sammlung kryptischer Befehle, sondern als wiederkehrende Prüfschleife behandelst:

ändern → status → diff → add → diff --staged → commit

Beginne lokal. Erstelle kleine, funktionierende Commits und prüfe vor jedem Commit die tatsächlich vorgemerkten Zeilen. GitHub, Branches und Team-Workflows können dazukommen, wenn du diesen Kern sicher beherrschst.

Ein Coding-Agent kann in Minuten sehr viel Code verändern. Mit Git behältst du die Entscheidung darüber, welche dieser Änderungen einen verlässlichen Zwischenstand deines Projekts bilden.