Grundlegende Befehle: init, add, commit, status, log

Grundlegende Git-Befehle

In L2 hast du die Begriffe gelernt – Repository, Commit, Branch, Staging Area. Diese Lektion zeigt die fünf wichtigsten Befehle in Aktion: git init, git status, git add, git commit, git log. Dazu git diff und die Erstkonfiguration. Damit kannst du lokal arbeiten – Remotes (push/pull) folgen in L4.

Wir bauen eine Mini-Historie Schritt für Schritt im Terminal-Simulator unten. Klick durch die Befehle und sieh, wie sich der Repo-Status verändert. Wer einen Linux-Rechner zur Hand hat: tipp parallel mit – das ist die beste Art, Git zu lernen.

1) Erstkonfiguration – einmal pro Rechner

Bevor du den ersten Commit machst, muss Git wissen, wer du bist. Diese Daten landen in jedem Commit, den du machst:

Globale Git-Konfiguration setzen

# Name und E-Mail global setzen (einmal pro Rechner): git config --global user.name "Anna Müller" git config --global user.email "anna@firma.de" # Default-Branch-Name für neue Repos auf "main" setzen: git config --global init.defaultBranch main # Editor für Commit-Messages (vim, nano, code): git config --global core.editor "code --wait" # Konfiguration prüfen: git config --list

Die Konfiguration landet in ~/.gitconfig (Linux/Mac) bzw. C:\Users\<Name>\.gitconfig (Windows). --global = gilt für alle Repos auf dem Rechner. Ohne --global nur für das aktuelle Repo. Wichtig: die E-Mail muss zu deinem GitHub-Account passen, sonst werden Commits dort nicht dir zugeordnet.

2) Terminal-Simulator – die fünf Kern-Befehle live

Spiel mit der Mini-Demo durch. Jeder Klick führt einen Befehl aus, die Ausgabe siehst du wie in einem echten Terminal:

Mini-Workflow im Simulator

anna@laptop: ~/mein-projekt

$ (Klick auf einen Button unten, um Befehle auszuführen)

Schritt für Schritt durchgegangen: Repo initialisieren → Datei erstellen → Status prüfen → Datei stagen → commiten → Datei ändern → Unterschied prüfen → wieder commiten → Historie ansehen. Dieser Mini-Zyklus ist die Grundoperation in Git. Sie wiederholt sich tausendfach pro Projekt.

3) Die Befehlsreferenz

Hier die Befehle aus dem Simulator als kompakte Referenz:

Befehlsreferenz

git init

Erstellt im aktuellen Ordner ein neues Git-Repo (legt .git/ an). Einmaliger Schritt zum Projektstart. Alternative: git clone <url> – wenn das Repo schon irgendwo existiert.

git status

Zeigt: welche Dateien sind untracked, modified, staged. Der wichtigste Befehl. Bei Unsicherheit immer als erstes nutzen. Kurzform: git status -s.

git add <datei>

Verschiebt Datei von Working Directory in die Staging Area. git add . = alle geänderten Dateien. git add -p = patch-mode, einzelne Hunks staging.

git commit -m "..."

Macht Snapshot aller staged Dateien mit Nachricht. Erstellt neuen Commit, HEAD bewegt sich. -am = add + commit in einem (nur bei bereits getrackten Dateien!).

git log

Zeigt Commit-Historie. git log --oneline = kompakt. git log --graph --all = mit Branches als ASCII-Graph. git log -p = mit Diffs.

git diff

Zeigt Änderungen seit dem letzten Commit (Working Directory). git diff --staged = was ist staged. git diff main feature = Branches vergleichen.

git restore <datei>

Wirft Änderungen einer Datei weg (Working Directory wird auf letzten Commit zurückgesetzt). Vorsicht: nicht rückgängig zu machen!

git reset HEAD <datei>

Entfernt Datei aus der Staging Area – Inhalt bleibt im Working Directory. Quasi „undo git add". Alternativ: git restore --staged <datei>.

Diese 8 Befehle decken 80 % der täglichen Git-Arbeit ab. Vor allem git status, git add, git commit und git log nutzt du mehrmals täglich. Tipp: leg dir Shell-Aliase an. alias gs='git status', alias gp='git push' sparen viel Zeit.

4) .gitignore – Dateien aussperren

Manche Dateien sollen nie ins Repo: Build-Output, Dependencies, IDE-Konfig, Secrets, Cache-Dateien. Lösung: .gitignore, eine Textdatei im Repo-Root:

Beispiel .gitignore

# Dependencies (Riesengröße, regenerierbar) node_modules/ __pycache__/ target/ build/ dist/ # IDE-Konfigurationen .vscode/ .idea/ *.iml # Logs und temporäre Dateien *.log *.tmp .DS_Store Thumbs.db # Secrets (NIEMALS commiten!) .env .env.local *.pem config/secrets.json # Compiled Output *.class *.pyc *.o

Wichtig: .gitignore wird selbst commitet, damit alle im Team dieselben Dateien ignorieren. Es gibt fertige Vorlagen pro Sprache/Framework auf github.com/github/gitignore. Achtung: Wenn eine Datei bereits getrackt ist, hilft .gitignore nicht mehr – erst git rm --cached <datei> ausführen, dann ignorieren.

5) Gute Commit-Messages

Eine Commit-Nachricht ist deine Erklärung für die Zukunft: warum habe ich das gemacht? Schlechte Messages („update", „fix") machen die Historie wertlos. Gute Messages sind Gold.

Schlechte vs. gute Commit-Messages

✗ Schlecht

fix

update

stuff

wip

asdf

final final version v3

✓ Gut

feat: Login-Endpoint hinzufügen

fix: Rabatt bei Senior-User (Alter ≥ 65)

refactor: PaymentService in Module aufteilen

docs: README mit Setup-Anleitung

test: Edge-Cases für Date-Parser

chore: Dependencies aktualisieren

style: ESLint-Warnings beheben

Der gute Stil hier nennt sich Conventional Commits (siehe conventionalcommits.org): jedes Commit beginnt mit einem Typ (feat, fix, refactor, docs, test, chore, style), dann ein Doppelpunkt, dann eine kurze Beschreibung. Wird von vielen Tools verstanden (automatische Changelog-Generierung, Release-Versionierung). In professionellen Projekten Standard.

6) Anatomie einer guten Commit-Message

Mehrzeilige Commit-Message

feat: Senior-Rabatt im Checkout berechnen Wenn der eingeloggte User älter als 65 ist, wird beim Checkout automatisch ein Rabatt von 30 % gewährt. Implementiert in PaymentService.calculateDiscount(). Refs: TICKET-1234 Closes: #87

Aufbau: 1. Zeile = Subject (max. 50 Zeichen, knapp und prägnant). Leerzeile. Body (umgebrochen bei ~72 Zeichen, erklärt das warum). Footer (optional: Ticket-Referenzen, Closes-Statements). Imperative Form benutzen: "fix bug" nicht "fixed bug". Mit git commit ohne -m öffnet sich der konfigurierte Editor, dort kannst du mehrzeilig schreiben.

7) Commit-Typen nach Conventional Commits

Standard-Commit-Typen

feat:

Neues Feature für die User. „feat: Suchfunktion in Produktliste".

fix:

Bugfix. „fix: NullPointer bei leerem Warenkorb".

refactor:

Code-Umstrukturierung, ohne neues Feature oder Bugfix. Vgl. K53 L5.

docs:

Nur Doku-Änderungen (README, Kommentare, JavaDoc).

test:

Tests hinzugefügt/geändert. Vgl. K52.

style:

Code-Style-Änderungen (Whitespace, Formatierung), keine logische Änderung.

chore:

Wartungsarbeit: Dependencies, Build-Konfig.

perf:

Performance-Verbesserung ohne neues Feature.

ci:

CI-Pipeline-Änderungen (GitHub Actions, GitLab CI).

8) Häufige Anfänger-Befehle für Notfälle

Vier Befehle, die du irgendwann brauchst – meist nach Tippfehlern:

git commit --amend – Letzten Commit korrigieren (Message ändern oder vergessene Dateien nachreichen). Nur wenn noch nicht gepusht!
git restore <datei> – Änderungen einer Datei verwerfen, zurück zum letzten Commit-Stand.
git restore --staged <datei> – Datei aus der Staging Area entfernen (Änderung bleibt).
git reset --soft HEAD~1 – Letzten Commit rückgängig machen, Änderungen bleiben staged. --hard wirft alles weg (gefährlich!).

Goldene Regel: Was committed und gepusht ist, kann man fast immer wiederherstellen. Was noch nicht committed ist, wird beim falschen Befehl unwiederbringlich gelöscht. Im Zweifel: git status, dann lieber jemanden fragen.

9) git diff verstehen

Die Ausgabe von git diff sieht zunächst kryptisch aus. So liest du sie:

git diff-Output entschlüsseln

diff --git a/index.js b/index.js index 8e3f2a..2c5b7d 100644 --- a/index.js // vorher +++ b/index.js // nachher @@ -10,3 +10,4 @@ // ab Zeile 10, 3 Zeilen alt, 4 neu function calc(x) { - return x * 1.19; // rote Zeile: entfernt + const tax = 1.19; // grüne Zeile: hinzugefügt + return x * tax; // grüne Zeile: hinzugefügt }

Wichtigste Zeichen: --- alte Datei, +++ neue Datei, @@ Position-Hunk-Header, - (rot) entfernt, + (grün) hinzugefügt. In GitHub-UI und in IDE-Diffs schöner dargestellt. Wer einen Pull Request reviewt, liest stundenlang Diffs – Übung lohnt sich.

10) Tipps für die ersten Tage

Klein und früh committen. Lieber 5 kleine Commits als einer mit 50 Änderungen. Macht Reviews und Reverts einfacher.
git status, git status, git status. Bei jedem Schritt prüfen, was passiert.
Nicht alles auf einmal stagen. Wenn du an mehreren Themen arbeitest: pro Thema einen Commit. git add -p hilft beim selektiven Stagen.
Pause vor dem Push. Bevor du pushst: nochmal mit git log --oneline die Commits ansehen. Stimmt das alles?
Nichts geheimes commiten. Passwörter, API-Keys, Tokens – einmal im Repo, schwer wieder los. .gitignore + Tools wie git-secrets schützen.
Eigene Spielwiese. Leg ein Test-Repo lokal an und probier alles aus: mkdir test-repo && cd test-repo && git init.

Zusammenfassung

Workflow: Code schreiben → git status → git add → git commit -m "..." → git log. Erstkonfig: user.name, user.email einmal pro Rechner. .gitignore für ignorierte Dateien (node_modules, .env, target/). Conventional Commits: feat:, fix:, refactor:, docs:, test:, chore:. Undo: git restore (Working Directory), git restore --staged (Stage), git commit --amend (letzten Commit). Nächste Lektion: Remotes – clone, push, pull, fetch.