Git kannst du lernen.

01Was Git macht

Die Grundidee in einem Satz

Git ist ein System, das Zustände deines Projekts speichert und dir erlaubt, jederzeit zu jedem gespeicherten Zustand zurückzukehren. Gespeichert wird das gesamte Projekt zu einem bestimmten Zeitpunkt.

Der Vergleich mit bericht_final_v2_wirklich_final.docx hilft: dieses Chaos löst Git. Statt Dateinamen zu verwalten, hast du eine Kette von Zuständen mit Zeitstempel, Autor und Beschreibung.

Drei Eigenschaften, die alles erklären

Das mentale Bild: eine Kette von Commits

Jeder Commit kennt seinen Vorgänger. Daraus entsteht eine lückenlose Kette. HEAD ist der Zeiger auf den Stand, an dem du gerade arbeitest.

02Einrichten und starten

Einmalige Konfiguration und der erste Schritt in ein Projekt

Identität setzen

Jeder Commit trägt einen Namen und eine E-Mail-Adresse. Das machst du einmal pro Computer.

# Name und Mail für alle Repositories auf diesem Rechner
git config --global user.name "Vorname Nachname"
git config --global user.email "du@beispiel.ch"

# Standardname des Hauptbranches
git config --global init.defaultBranch main

# Kontrolle
git config --list

Zwei Wege in ein Projekt

# Weg 1: bestehenden Ordner unter Versionskontrolle stellen
cd mein-projekt
git init

# Weg 2: bestehendes Repository von GitHub kopieren
git clone https://github.com/benutzer/projekt.git

git init legt einen versteckten Ordner .git an. Darin liegt die komplette Historie. Löschst du diesen Ordner, ist die Versionsgeschichte weg, die Dateien bleiben.

.gitignore anlegen

Nicht alles gehört in die Historie. Generierte Dateien, Abhängigkeiten und Geheimnisse bleiben draussen.

# Abhängigkeiten
node_modules/
vendor/

# Build-Ergebnisse
dist/
build/

# Geheimnisse und lokale Konfiguration
.env
.env.local
*.key

# Systemdateien
.DS_Store
Thumbs.db

03Die drei Bereiche

Das Konzept, an dem die meisten Anfänger scheitern

Eine Änderung durchläuft in Git drei Stationen. Wer diese drei Bereiche verstanden hat, versteht neunzig Prozent der alltäglichen Befehle.

# Wo steht was gerade
git status

# Einzelne Datei vormerken
git add index.html

# Alles vormerken
git add .

# Interaktiv einzelne Abschnitte einer Datei auswählen
git add -p

# Aus der Staging Area zurücknehmen, Änderung bleibt erhalten
git restore --staged index.html

04Der Commit

Der wichtigste Vorgang in Git

Ein Commit friert den Inhalt der Staging Area dauerhaft ein und ergänzt ihn um Autor, Zeitstempel, Nachricht und einen Verweis auf den vorherigen Commit. Er erhält eine eindeutige Prüfsumme, den Hash, zum Beispiel a1b2c3d.

# Commit mit kurzer Nachricht
git commit -m "Login-Formular validiert Eingaben"

# Alle bereits bekannten Dateien vormerken und committen
git commit -am "Tippfehler in der Navigation korrigiert"

# Letzten Commit korrigieren, solange er nicht gepusht ist
git commit --amend

Gute Commit-Nachrichten

Die Nachricht ist für die Person gedacht, die in sechs Monaten wissen will, warum etwas geändert wurde. Bewährt hat sich: Betreffzeile unter 50 Zeichen, im Imperativ, ohne Punkt am Ende. Bei Bedarf folgt nach einer Leerzeile die Begründung.

Conventional Commits

Viele Teams nutzen ein festes Präfix, weil sich daraus automatisch Changelogs erzeugen lassen.

feat: Export als PDF ergänzt
fix: Datumsformat in der Rechnungsliste korrigiert
docs: Installationsanleitung aktualisiert
refactor: Preislogik in eigenes Modul ausgelagert
test: Testfälle für Rabattberechnung ergänzt
chore: Abhängigkeiten aktualisiert

05Historie lesen

Nachvollziehen, was wann von wem geändert wurde

# Vollständige Historie
git log

# Kompakt, eine Zeile pro Commit
git log --oneline

# Mit grafischer Darstellung der Branches
git log --oneline --graph --all

# Nur eine bestimmte Datei
git log -p src/preise.js

# Wer hat welche Zeile geschrieben
git blame src/preise.js

# Unterschiede zum letzten Commit
git diff

# Unterschiede der vorgemerkten Änderungen
git diff --staged

# Einen bestimmten Commit ansehen
git show a1b2c3d

git blame klingt nach Schuldzuweisung, ist aber ein Recherchewerkzeug: es zeigt zu jeder Zeile den Commit, aus dem sie stammt. Von dort kommst du zur Begründung.

06Branches

Parallel arbeiten, ohne den Hauptstand zu gefährden

Ein Branch ist technisch nur ein Zeiger auf einen Commit. Deshalb ist das Erstellen eines Branches in Git sofort erledigt und kostet praktisch nichts. Der Hauptbranch heisst heute meist main, in älteren Projekten master.

# Alle Branches anzeigen
git branch

# Branch erstellen und direkt wechseln
git switch -c feature/suche

# Zwischen Branches wechseln
git switch main

# Ältere Schreibweise, macht dasselbe
git checkout -b feature/suche

# Branch umbenennen
git branch -m alter-name neuer-name

# Zusammengeführten Branch löschen
git branch -d feature/suche

Namenskonventionen

• feature/kundenexport für neue Funktionen
• fix/login-absturz für Fehlerbehebungen
• hotfix/zahlungsfehler für dringende Korrekturen an der laufenden Version
• docs/readme für reine Dokumentation

07Merge und Rebase

Zwei Wege, Arbeit zusammenzuführen

Merge

Merge führt zwei Entwicklungslinien zusammen und erzeugt dabei in der Regel einen zusätzlichen Merge-Commit. Die Historie bleibt so, wie es passiert ist, inklusive der Verzweigungen.

# Auf den Zielbranch wechseln
git switch main

# Aktuellen Stand holen
git pull

# Feature-Branch hineinführen
git merge feature/suche

Rebase

Rebase setzt deine Commits neu auf die Spitze des Zielbranches. Das Ergebnis ist eine gerade Linie ohne Verzweigungen. Die Commits werden dabei neu erzeugt und erhalten neue Prüfsummen.

# Eigenen Branch auf den aktuellen main setzen
git switch feature/suche
git rebase main

# Letzte drei Commits aufräumen, zusammenfassen, umbenennen
git rebase -i HEAD~3

08Konflikte lösen

Eine Rückfrage von Git, kein Fehler

Git führt parallele Änderungen selbständig zusammen, solange sie unterschiedliche Zeilen betreffen. Ein Konflikt entsteht nur, wenn zwei Branches dieselbe Zeile unterschiedlich verändert haben. Git kann dann nicht entscheiden und fragt dich.

function berechnePreis(betrag) {
<<<<<<< HEAD
  return betrag * 1.081;
=======
  return betrag * 1.077;
>>>>>>> feature/mwst-anpassung
}

• Zwischen <<<<<<< HEAD und ======= steht deine Version.
• Zwischen ======= und >>>>>>> steht die Version des anderen Branches.
• Du entscheidest, was gilt, und löschst alle Markierungszeilen.

# Welche Dateien betroffen sind
git status

# Nach dem Bearbeiten als gelöst markieren
git add preise.js
git commit

# Den ganzen Merge abbrechen und zurück zum Ausgangspunkt
git merge --abort

09Remote, Push und Pull

Der Weg vom eigenen Rechner zum Server

Ein Remote ist eine benannte Adresse eines anderen Repositories, meist auf GitHub. Der Standardname ist origin. Ohne Push bleibt dein Commit ausschliesslich lokal.

# Welche Remotes sind eingetragen
git remote -v

# Remote hinzufügen
git remote add origin git@github.com:benutzer/projekt.git

# Erster Push, Branch wird verknüpft
git push -u origin main

# Danach reicht
git push

# Änderungen holen, ohne sie einzubauen
git fetch

# Holen und direkt zusammenführen
git pull

# Holen und die eigenen Commits obendrauf setzen
git pull --rebase

HTTPS oder SSH

Bei HTTPS meldest du dich mit Benutzername und einem Personal Access Token an. Bei SSH hinterlegst du einmal einen Schlüssel auf GitHub und musst dich danach nicht mehr anmelden.

# Schlüssel erzeugen
ssh-keygen -t ed25519 -C "du@beispiel.ch"

# Öffentlichen Teil anzeigen und auf GitHub hinterlegen
cat ~/.ssh/id_ed25519.pub

# Verbindung testen
ssh -T git@github.com

10Was GitHub dazugibt

Die Plattform um Git herum

Git verwaltet Versionen. Alles, was mit Zusammenarbeit zu tun hat, kommt von der Plattform.

README und Lizenz

Die Datei README.md wird auf der Startseite des Repositories angezeigt. Sie beantwortet drei Fragen: Was ist das, wie installiere ich es, wie benutze ich es. Ohne Lizenzdatei behalten sich die Urheber alle Rechte vor, auch bei öffentlichem Code.

11Fork und Pull Request

Mitarbeiten an Projekten, auf die du keinen Schreibzugriff hast

Der komplette Ablauf

1. Auf GitHub oben rechts auf Fork klicken. Du erhältst eine Kopie unter deinem Konto.
2. Deinen Fork lokal klonen.
3. Das Originalprojekt als zweites Remote namens upstream eintragen.
4. Einen Branch für deine Änderung anlegen.
5. Arbeiten, committen, in deinen Fork pushen.
6. Auf GitHub den Pull Request gegen das Original eröffnen.

# 2. Den eigenen Fork klonen
git clone git@github.com:deinname/projekt.git
cd projekt

# 3. Original als upstream eintragen
git remote add upstream git@github.com:original/projekt.git

# Fork aktuell halten
git fetch upstream
git switch main
git merge upstream/main
git push origin main

# 4. bis 5. Arbeiten und hochladen
git switch -c fix/tippfehler-doku
git commit -am "Tippfehler in der Installationsanleitung korrigiert"
git push -u origin fix/tippfehler-doku

Was einen guten Pull Request ausmacht

• Ein Thema pro Pull Request. Keine drei unabhängigen Änderungen mischen.
• Beschreibung mit Kontext: was, warum, wie getestet.
• Verweis auf das zugehörige Issue, zum Beispiel Closes #42.
• Kommentare aus dem Review als Frage verstehen, nicht als Angriff.

12Team-Workflows

Wie Teams ihre Branches organisieren

GitHub Flow

Der einfachste und heute verbreitetste Ansatz. main ist immer auslieferbar. Für jede Änderung entsteht ein kurzlebiger Branch, der über einen Pull Request zurückfliesst und danach gelöscht wird. Gut geeignet für Webprojekte mit häufigen Releases.

Git Flow

Älterer, formaler Ansatz mit dauerhaften Branches main und develop sowie Feature-, Release- und Hotfix-Branches. Sinnvoll bei Software mit festen Versionsständen, zum Beispiel Desktop-Anwendungen. Für die meisten Webprojekte zu schwerfällig.

Trunk Based Development

Alle arbeiten sehr nah an main, Branches leben nur Stunden. Unfertige Funktionen werden per Feature Flag ausgeblendet. Setzt eine starke Testautomatisierung voraus.

Branch Protection

Auf GitHub lässt sich main schützen: kein direkter Push, mindestens eine Genehmigung im Review, Tests müssen grün sein. Das ist der wirksamste Schutz gegen versehentliche Fehler in der Produktion.

13Deployment verstehen

Vom Commit zur laufenden Anwendung

Deployment ist der Vorgang, bei dem dein Code auf einem Server landet und für Nutzer erreichbar wird. Git speichert Versionen, das Deployment bringt eine davon in Betrieb. Das sind zwei getrennte Schritte, auch wenn moderne Werkzeuge sie verketten.

Umgebungen

Statisch oder dynamisch

Eine statische Website besteht aus fertigen HTML-, CSS- und JS-Dateien. Das Deployment ist reines Kopieren, etwa auf GitHub Pages, Netlify oder Vercel. Eine dynamische Anwendung braucht einen laufenden Prozess und meist eine Datenbank. Das Deployment umfasst dann auch Neustart und Datenbankmigrationen.

GitHub Pages in vier Schritten

1. Repository auf GitHub anlegen und Dateien pushen.
2. Unter Settings zu Pages wechseln.
3. Als Quelle den Branch main und den Ordner /root wählen.
4. Nach kurzer Zeit ist die Seite unter benutzername.github.io/projekt erreichbar.

14GitHub Actions und CI/CD

Automatisierung bei jedem Push

Continuous Integration bedeutet: bei jeder Änderung laufen automatisch Tests und Prüfungen. Continuous Deployment bedeutet: was die Prüfungen besteht, wird automatisch ausgeliefert. Auf GitHub läuft beides über Workflow-Dateien im Ordner .github/workflows/.

name: Tests und Deployment

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - name: Ausliefern
        run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

15Fehler rückgängig machen

Der Abschnitt, den du in der Praxis am häufigsten brauchst

reset oder revert

git reset entfernt Commits aus der Historie. Das ist in Ordnung, solange nichts gepusht wurde. git revert erzeugt einen neuen Commit, der die Änderung aufhebt. Das ist der richtige Weg für alles, was bereits geteilt ist, weil die Historie erhalten bleibt.

git reflog als Sicherheitsnetz

Git protokolliert jede Bewegung von HEAD. Fast nichts geht verloren, auch nach einem harten Reset.

# Alle Bewegungen von HEAD anzeigen
git reflog

# Zum gewünschten Zustand zurückkehren
git reset --hard HEAD@{3}

16Befehlsreferenz

40 Befehle, durchsuchbar, zum Nachschlagen im Alltag

Tippen filtert die Tabelle sofort.

17Glossar

Begriffe, die in Diskussionen und Dokumentationen vorkommen

18Quiz

Zehn Fragen zur Selbstkontrolle, mit Erklärung nach jeder Antwort

+Weiterlernen

• Die Hüter der Historie, das Spiel zu diesem Lernpfad: 6 interaktive Level und eine Prüfung
• Pro Git Buch, das offizielle Handbuch, kostenlos und auf Deutsch
• Learn Git Branching, interaktive Übungen zu Branches und Merges
• GitHub Docs, Referenz zu Pull Requests, Actions und Pages
• Oh Shit, Git, Rettungswege für typische Fehlersituationen