Git & GitHub mit PhpStorm

Komplexe Projekte erfordern Versionsmanagement.

Als PDF: https://li.fabula.vision/git-pdf | Hier geht es zum Kurs für Fortgeschrittene.

Wenn manchmal eine Bombe (💣) zu sehen, dann muss man die Website mit Ctrl+F5 aktualisieren. (Irgendwas stimmt nicht mit meinem Script zur Darstellung von Diagrammen…)

Git & GitHub – Ultra-Schnellstart Cheat Sheet 🚀

Dieses Cheat Sheet gibt dir alle wichtigen Befehle und Konzepte auf einen Blick, damit du sofort mit Git und GitHub loslegen kannst. Es ist als Nachschlagewerk gedacht – wenn du die Hintergründe verstehen willst, schau in die ausführlichen Kapitel deines Kurses.

Die drei Bereiche von Git verstehen

Bevor du mit den Befehlen loslegst, solltest du das grundlegende Konzept verinnerlichen:

flowchart LR
    WD["🗂️ Working Directory\nDein Arbeitsordner"] -->|git add| SA["📋 Staging Area\nVorbereitungsbereich"]
    SA -->|git commit| REPO["📦 Repository\nVersionshistorie"]
    REPO -->|git push| REMOTE["☁️ Remote\nz.B. GitHub"]
    REMOTE -->|git pull| WD
Bereich Beschreibung
Working Directory Dein aktueller Projektordner mit allen Dateien, an denen du arbeitest
Staging Area Der „Vorbereitungsraum" – hier sammelst du Änderungen für den nächsten Commit
Repository Die lokale Datenbank mit der kompletten Versionshistorie
Remote Ein entferntes Repository (z.B. auf GitHub), um Code zu teilen oder zu sichern

Ersteinrichtung

Diese Befehle führst du einmalig nach der Git-Installation aus:

# Deinen Namen setzen (erscheint in jedem Commit)
git config --global user.name "Dein Name"

# Deine E-Mail setzen (sollte mit GitHub übereinstimmen)
git config --global user.email "deine@email.de"

# Standardbranch auf "main" setzen (moderne Konvention)
git config --global init.defaultBranch main

# Konfiguration überprüfen
git config --list

💡 Tipp: Die --global-Option setzt die Einstellung für alle Repositories auf deinem Computer. Ohne diese Option gilt sie nur für das aktuelle Projekt.

Repository erstellen und klonen

Aktion Befehl
Neues Repository im aktuellen Ordner erstellen git init
Bestehendes Repository von GitHub klonen git clone https://github.com/user/repo.git
Repository mit eigenem Ordnernamen klonen git clone https://github.com/user/repo.git mein-ordner

Der tägliche Workflow

Dies sind die Befehle, die du am häufigsten verwenden wirst:

Status und Änderungen prüfen

# Aktuellen Status anzeigen (welche Dateien geändert, gestaged, etc.)
git status

# Kurzversion des Status
git status -s

# Änderungen im Working Directory anzeigen (noch nicht gestaged)
git diff

# Änderungen in der Staging Area anzeigen (bereit für Commit)
git diff --staged

Dateien stagen und committen

# Einzelne Datei zur Staging Area hinzufügen
git add dateiname.php

# Mehrere Dateien hinzufügen
git add datei1.php datei2.php ordner/

# ALLE geänderten und neuen Dateien hinzufügen
git add .

# Commit erstellen mit Nachricht
git commit -m "Kurze, aussagekräftige Beschreibung"

# Staging und Commit in einem Schritt (nur für bereits getrackte Dateien!)
git commit -am "Beschreibung"

Letzten Commit korrigieren

# Nachricht des letzten Commits ändern
git commit --amend -m "Neue, korrigierte Nachricht"

# Vergessene Dateien zum letzten Commit hinzufügen
git add vergessene-datei.php
git commit --amend --no-edit

⚠️ Wichtig: Verwende --amend nur für Commits, die du noch nicht gepusht hast! Andernfalls überschreibst du die Historie, die andere bereits haben könnten.

Mit GitHub arbeiten

Remote-Verbindung einrichten

# Remote-Repository hinzufügen (einmalig nach git init)
git remote add origin https://github.com/dein-user/dein-repo.git

# Alle konfigurierten Remotes anzeigen
git remote -v

# Remote-URL ändern
git remote set-url origin https://github.com/user/neues-repo.git

Push und Pull

# Lokale Commits zum Remote-Repository hochladen
git push origin main

# Beim ersten Push den Upstream-Branch setzen (danach reicht "git push")
git push -u origin main

# Änderungen vom Remote-Repository holen und mergen
git pull origin main

# Nur Informationen holen, ohne zu mergen
git fetch origin

Branches – parallele Entwicklungslinien

Branches sind eines der mächtigsten Features von Git. Nutze sie, um Features zu entwickeln, ohne den Hauptcode zu gefährden.

Branch-Übersicht

# Alle lokalen Branches anzeigen (aktueller Branch mit * markiert)
git branch

# Alle Branches inkl. Remote-Branches anzeigen
git branch -a

# Neuen Branch erstellen
git branch feature-name

# Branch erstellen UND direkt wechseln
git checkout -b feature-name
# oder moderner:
git switch -c feature-name

Zwischen Branches wechseln

# Zu bestehendem Branch wechseln
git checkout feature-name
# oder moderner:
git switch feature-name

# Zurück zum main-Branch
git switch main

Branches zusammenführen und löschen

# Zuerst in den Zielbranch wechseln (z.B. main)
git switch main

# Anderen Branch in aktuellen Branch mergen
git merge feature-name

# Branch löschen (nach erfolgreichem Merge)
git branch -d feature-name

# Branch löschen (erzwingen, auch wenn nicht gemergt)
git branch -D feature-name

# Remote-Branch löschen
git push origin --delete feature-name

Historie und Logs

# Commit-Historie anzeigen
git log

# Kompakte einzeilige Darstellung
git log --oneline

# Mit grafischer Branch-Darstellung
git log --oneline --graph --all

# Die letzten n Commits anzeigen
git log -5

# Historie einer bestimmten Datei
git log -- dateiname.php

# Wer hat welche Zeile geschrieben?
git blame dateiname.php

Änderungen rückgängig machen

Situation Befehl
Änderungen im Working Directory verwerfen (Datei auf letzten Commit zurücksetzen) git checkout -- datei.php oder git restore datei.php
Datei aus Staging Area entfernen (aber Änderungen behalten) git reset HEAD datei.php oder git restore --staged datei.php
Letzten Commit rückgängig machen (Änderungen bleiben im Working Directory) git reset --soft HEAD~1
Letzten Commit komplett verwerfen (Änderungen werden gelöscht!) git reset --hard HEAD~1
Einen früheren Commit „umkehren" (neuer Commit, der Änderungen rückgängig macht) git revert <commit-hash>

⚠️ Vorsicht mit --hard! Dieser Befehl löscht Änderungen unwiderruflich. Nutze ihn nur, wenn du dir sicher bist.

Die .gitignore-Datei

Erstelle im Projektroot eine Datei namens .gitignore, um bestimmte Dateien vom Tracking auszuschließen:

# Abhängigkeiten (werden mit Composer/npm installiert)
/vendor/
/node_modules/

# IDE-Einstellungen
/.idea/
/.vscode/

# Umgebungsvariablen und Secrets
.env
.env.local
*.log

# Betriebssystem-Dateien
.DS_Store
Thumbs.db

# Kompilierte/generierte Dateien
/dist/
/build/
*.cache

💡 Tipp: Füge die .gitignore früh zu deinem Projekt hinzu – am besten direkt nach git init. Bereits getrackte Dateien werden nicht automatisch ignoriert.

Gute Commit-Nachrichten schreiben

Eine gute Commit-Nachricht folgt diesem Muster:

<Typ>: <Was wurde geändert> (kurz, im Imperativ)

[Optional: Ausführlichere Beschreibung nach einer Leerzeile]

Beispiele für gute Nachrichten:

✅ Gut ❌ Schlecht
feat: Kontaktformular mit Validierung hinzugefügt update
fix: Null-Pointer-Exception bei leerem Warenkorb behoben bug gefixt
refactor: Datenbankabfragen in eigene Klasse ausgelagert änderungen
docs: README mit Installationsanleitung aktualisiert asdf

Gängige Präfixe:

PhpStorm-Shortcuts 🖱️

Wenn du PhpStorm nutzt, kannst du die meisten Git-Operationen direkt in der IDE ausführen:

Aktion Shortcut (Windows/Linux) Shortcut (macOS)
Commit-Dialog öffnen Ctrl + K Cmd + K
Push Ctrl + Shift + K Cmd + Shift + K
Pull/Update Ctrl + T Cmd + T
Git-Log anzeigen Alt + 9 Cmd + 9
Branches verwalten Ctrl + Shift + ´ Ctrl + V dann Branches
VCS-Popup Alt + ´ (Backtick) Ctrl + V

Typischer Workflow auf einen Blick

flowchart TD
    A["1. Branch erstellen\ngit switch -c feature-xy"] --> B["2. Code schreiben\nund Dateien ändern"]
    B --> C["3. Änderungen prüfen\ngit status"]
    C --> D["4. Dateien stagen\ngit add ."]
    D --> E["5. Commit erstellen\ngit commit -m '...'"]
    E --> F{"Fertig mit\nFeature?"}
    F -->|Nein| B
    F -->|Ja| G["6. Zurück zu main\ngit switch main"]
    G --> H["7. Updates holen\ngit pull origin main"]
    H --> I["8. Feature mergen\ngit merge feature-xy"]
    I --> J["9. Hochladen\ngit push origin main"]
    J --> K["10. Branch löschen\ngit branch -d feature-xy"]

Schnellreferenz – die 15 wichtigsten Befehle

# Befehl Beschreibung
1 git init Neues Repository erstellen
2 git clone <url> Repository von Remote klonen
3 git status Aktuellen Zustand anzeigen
4 git add . Alle Änderungen stagen
5 git commit -m "..." Commit erstellen
6 git push Commits hochladen
7 git pull Änderungen herunterladen und mergen
8 git log --oneline Historie anzeigen
9 git branch Branches auflisten
10 git switch -c <name> Neuen Branch erstellen und wechseln
11 git switch <name> Zu Branch wechseln
12 git merge <branch> Branch zusammenführen
13 git diff Änderungen anzeigen
14 git restore <datei> Änderungen verwerfen
15 git remote -v Remote-Verbindungen anzeigen

🎯 Merke dir: Mit nur fünf Befehlen (status, add, commit, push, pull) kommst du im Alltag schon sehr weit. Alles andere lernst du nach und nach, wenn du es brauchst!

Kapitel 1: Orientierung – Was sind Git, GitHub und warum brauche ich das?

Einleitung: Bevor du in die Praxis einsteigst, ist es wichtig zu verstehen, welches Problem Git eigentlich löst. Stell dir vor, du arbeitest wochenlang an einem Projekt, änderst Code, löschst Dateien – und plötzlich funktioniert nichts mehr. Ohne Versionsverwaltung hast du keine Möglichkeit, zu einem funktionierenden Stand zurückzukehren. Git ist wie eine Zeitmaschine für deinen Code: Es speichert jeden Zwischenstand deines Projekts und ermöglicht dir, jederzeit in die Vergangenheit zu reisen. GitHub ergänzt Git um eine Online-Plattform, auf der du deinen Code sichern und mit anderen teilen kannst. In diesem Kapitel lernst du die grundlegenden Konzepte und Begriffe kennen, die du für den Rest des Kurses brauchst.

Kapitel 1: Orientierung – Was sind Git, GitHub und warum brauche ich das?

Was ist Versionsverwaltung – und warum ist Git so wichtig? 📚

Versionsverwaltung ist ein System, mit dem du Änderungen an Dateien — vor allem an Quellcode — nachvollziehen, organisieren und bei Bedarf rückgängig machen kannst.

Stell dir vor, du arbeitest an einem Projekt und speicherst Dateien so ab:

😅 Genau dieses Chaos versucht Versionsverwaltung zu verhindern.

Stattdessen speichert ein Versionsverwaltungssystem gezielt, wer was wann geändert hat und erlaubt dir, auf frühere Stände zurückzugehen, Änderungen zu vergleichen und sauber weiterzuarbeiten.

Das Grundproblem ohne Versionsverwaltung

Wenn du ohne Git an echten Projekten arbeitest, tauchen sehr schnell typische Probleme auf:

  1. Du verlierst den Überblick über Änderungen

    • Was hast du gestern geändert?
    • Warum funktioniert plötzlich etwas nicht mehr?
    • Welche Datei war zuletzt noch korrekt?

  2. Fehler lassen sich schwer zurückverfolgen

    • Ein Bug ist plötzlich da, aber du weißt nicht, ab wann.
    • Du kannst nicht einfach elegant zu einem funktionierenden Stand zurückspringen.

  3. Experimentieren wird riskant

    • Du willst etwas umbauen, hast aber Angst, das funktionierende System kaputtzumachen.
    • Deshalb kopierst du oft ganze Projektordner als „Sicherheitskopie“.

  4. Zusammenarbeit wird chaotisch

    • Wenn mehrere Personen dieselben Dateien ändern, ist schnell unklar:
      • Welche Version ist die richtige?
      • Welche Änderung soll behalten werden?
      • Wer hat was gemacht?

  5. Deployment und Releases werden unübersichtlich

    • Du weißt irgendwann nicht mehr genau, welcher Stand live gegangen ist.
    • Hotfixes und neue Features vermischen sich.

Was Versionsverwaltung konkret macht

Eine Versionsverwaltung hilft dir dabei, dein Projekt historisch und strukturiert zu verwalten.

Typische Funktionen sind:

Im Kern entsteht eine Projektgeschichte, die nicht nur den aktuellen Stand zeigt, sondern auch den Weg dorthin.

Und was ist Git dabei genau?

Git ist ein sehr verbreitetes Versionsverwaltungssystem, speziell für Softwareprojekte.

Es ist dafür gemacht, dass du:

Der wichtigste Gedanke dabei ist:

Git speichert nicht einfach nur „Dateien“, sondern die Entwicklung deines Projekts in nachvollziehbaren Schritten.

Diese Schritte heißen Commits.

Ein Commit ist vereinfacht gesagt ein gespeicherter Meilenstein deines Projekts.

Zum Beispiel:

So entsteht nach und nach eine saubere Historie.

Welches Problem löst Git in echten Programmierprojekten?

Git löst nicht nur ein Problem, sondern gleich mehrere zentrale Probleme in der Praxis.

1. Git schafft Sicherheit

Wenn du an Code arbeitest, wirst du Fehler machen — das ist völlig normal.
Mit Git ist das nicht dramatisch, weil du frühere Stände wiederfinden kannst.

Das bedeutet:

Ohne Git fühlt sich jeder größere Umbau riskant an.
Mit Git weißt du: „Wenn etwas schiefgeht, komme ich wieder zurück.“

2. Git macht Änderungen nachvollziehbar

Git zeigt dir genau:

Das ist extrem hilfreich, wenn du dich fragst:

Gerade bei Lernprojekten ist das Gold wert, weil du dadurch auch deinen eigenen Fortschritt besser verstehst.

3. Git ermöglicht sauberes Experimentieren mit Branches

Ein Branch ist ein separater Entwicklungszweig.

Damit kannst du zum Beispiel:

…ohne den stabilen Hauptstand direkt zu gefährden.

Das ist viel besser als:

Mit Git kannst du also geordnet experimentieren statt chaotisch improvisieren.

4. Git verbessert die Zusammenarbeit

Sobald mehrere Menschen an einem Projekt arbeiten, wird Versionsverwaltung praktisch unverzichtbar.

Git hilft dabei, dass:

  1. jede Person ihre Änderungen machen kann
  2. diese Änderungen zusammengeführt werden können
  3. Konflikte sichtbar werden, wenn zwei Personen dieselbe Stelle geändert haben
  4. die Projektgeschichte erhalten bleibt

Dadurch wird Teamarbeit überhaupt erst kontrollierbar.

5. Git schafft professionelle Arbeitsweise

Fast alle modernen Softwareprojekte nutzen Git oder ein ähnliches System.
Wenn du Git lernst, lernst du also nicht nur ein Tool, sondern auch eine grundlegende Arbeitsweise der Softwareentwicklung.

Dazu gehören unter anderem:

Ein einfaches Alltagsbeispiel

Stell dir vor, du schreibst an einer Hausarbeit.

Ohne Versionsverwaltung würdest du vielleicht so arbeiten:

Mit Versionsverwaltung hättest du stattdessen eine geordnete Historie:

  1. Gliederung erstellt
  2. Einleitung geschrieben
  3. Kapitel 2 ergänzt
  4. Rechtschreibung korrigiert
  5. Fazit überarbeitet

Und du könntest jederzeit sagen:

Genau das macht Git — nur eben für Code und Projekte.

Warum ist das gerade für dich als Einsteiger sinnvoll?

Vielleicht denkst du am Anfang:

„Ich programmiere doch erstmal nur allein — brauche ich Git wirklich schon?“

Ja, absolut. Gerade dann.

Denn Git hilft dir schon früh dabei:

Wenn du Git erst sehr spät lernst, hast du dir oft schon unpraktische Gewohnheiten angewöhnt.
Wenn du Git früh lernst, wird sauberes Arbeiten von Anfang an normal. 👍

Was Git nicht ist

Wichtig ist auch, ein paar Missverständnisse zu vermeiden:

Git ist nicht:

Git ist das Versionsverwaltungssystem.
GitHub ist eine Online-Plattform, auf der Git-Repositories gespeichert und geteilt werden können.

Diesen Unterschied schauen wir uns im nächsten Schritt noch genauer an.

Kurz zusammengefasst

Versionsverwaltung bedeutet, Änderungen an einem Projekt systematisch zu speichern und nachvollziehbar zu machen.

Git löst dabei in echten Programmierprojekten vor allem diese Probleme:

Oder in einem Satz:

Git gibt deinem Projekt ein Gedächtnis.

Merksatz 🧠

Ohne Versionsverwaltung arbeitest du oft nur am aktuellen Zustand.
Mit Git arbeitest du zusätzlich mit der gesamten Geschichte deines Projekts.

Kapitel 1: Orientierung – Was sind Git, GitHub und warum brauche ich das?

Die wichtigsten Git-Grundbegriffe für Einsteiger 📘

Bevor du mit Git arbeitest, solltest du ein paar zentrale Begriffe verstehen. Diese tauchen in fast jeder Anleitung auf – und sobald du sie verinnerlicht hast, wird alles andere viel leichter verständlich.

Repository – dein Projektarchiv 📁

Ein Repository (kurz: Repo) ist im Grunde ein Ordner mit Gedächtnis. Es enthält alle Dateien deines Projekts und die komplette Änderungshistorie – also wer wann was geändert hat.

Es gibt zwei Arten:

💡 Wenn du in PhpStorm ein Projekt „unter Git-Kontrolle stellst", erstellst du ein lokales Repository.

Stage (Staging Area) – die Vorbereitungszone 📋

Die Staging Area ist eine Art Wartezone zwischen deinen Änderungen und dem nächsten Commit. Wenn du eine Datei änderst, ist sie zunächst nur im sogenannten Working Directory verändert. Erst wenn du sie „stagst", signalisierst du Git: „Diese Änderung soll Teil des nächsten Commits sein."

Das Vorgehen ist also:

  1. Du änderst Dateien (Working Directory)
  2. Du wählst aus, welche Änderungen gespeichert werden sollen → Stage
  3. Du speicherst diese Auswahl dauerhaft → Commit

💡 Das ist praktisch, weil du nicht immer alle Änderungen auf einmal speichern musst, sondern gezielt auswählen kannst.

Commit – ein Schnappschuss deines Projekts 📸

Ein Commit ist ein gespeicherter Zustand deines Projekts zu einem bestimmten Zeitpunkt. Jeder Commit enthält eine eindeutige ID (einen sogenannten Hash), eine Nachricht, die beschreibt was geändert wurde, den Autor und das Datum sowie die tatsächlichen Änderungen an den Dateien.

Commits sind das Herzstück von Git. Du kannst sie dir wie Speicherpunkte in einem Videospiel vorstellen – du kannst jederzeit zu einem früheren Commit zurückkehren.

Beispiel einer Commit-Historie:
───────────────────────────────
Commit 3: "Login-Formular validiert"
Commit 2: "Login-Seite erstellt"
Commit 1: "Projektstruktur angelegt"

Branch – parallele Entwicklungslinien 🌿

Ein Branch ist ein eigenständiger Entwicklungszweig. Standardmäßig arbeitest du auf dem Branch namens main (früher oft master). Du kannst aber jederzeit einen neuen Branch erstellen, um z. B. ein neues Feature zu entwickeln – ohne den Hauptzweig zu beeinflussen.

gitGraph
    commit id: "Start"
    commit id: "Basis fertig"
    branch feature/login
    commit id: "Login-Seite"
    commit id: "Validierung"
    checkout main
    commit id: "Bugfix"
    merge feature/login id: "Merge"

💡 Branches sind wie parallele Universen deines Projekts – du kannst experimentieren, ohne das „echte" Projekt zu gefährden.

Merge – Zweige zusammenführen 🔀

Wenn du mit der Arbeit in einem Branch fertig bist, möchtest du diese Änderungen meist zurück in den main-Branch bringen. Diesen Vorgang nennt man Merge.

Git versucht dabei, die Änderungen automatisch zusammenzuführen. Falls jedoch dieselbe Stelle in beiden Branches unterschiedlich geändert wurde, entsteht ein Merge-Konflikt, den du manuell lösen musst. PhpStorm bietet dafür ein praktisches visuelles Tool.

Remote – die Verbindung zur Außenwelt 🌐

Ein Remote ist eine Referenz auf ein externes Repository, typischerweise auf GitHub, GitLab oder Bitbucket. Der Standard-Remote heißt meist origin.

Wenn du ein Projekt auf GitHub hast und lokal damit arbeitest, ist origin die Brücke zwischen deinem Computer und GitHub:

Begriff Bedeutung
origin Der Name des Remote-Repositorys (meist auf GitHub)
Remote-URL Die Adresse, z. B. https://github.com/user/projekt.git

Clone – ein bestehendes Projekt herunterladen 📥

Clone bedeutet, ein komplettes Remote-Repository auf deinen Computer zu kopieren – inklusive aller Dateien und der gesamten Historie.

git clone https://github.com/beispiel/projekt.git

💡 In PhpStorm kannst du über „Get from VCS" direkt ein GitHub-Projekt clonen und sofort loslegen.

Push und Pull – Synchronisation mit dem Remote 🔄

Diese beiden Begriffe beschreiben den Datenaustausch zwischen deinem lokalen Repository und dem Remote:

flowchart LR
    A["Lokales Repository<br>auf deinem PC"] -->|Push| B["Remote Repository<br>z.B. auf GitHub"]
    B -->|Pull| A

Zusammenfassung auf einen Blick 🗺️

Begriff Kurzerklärung
Repository Projektordner mit kompletter Änderungshistorie
Stage Vorauswahl der Änderungen für den nächsten Commit
Commit Gespeicherter Schnappschuss des Projektzustands
Branch Paralleler Entwicklungszweig
Merge Zusammenführen zweier Branches
Remote Verbindung zu einem externen Repository
Clone Komplettes Repository herunterladen
Push Lokale Commits zum Remote hochladen
Pull Änderungen vom Remote herunterladen

Mit diesen Begriffen im Hinterkopf wirst du die folgenden Kapitel deutlich leichter verstehen – sie bilden das Vokabular, mit dem Git „spricht". 🎯

Kapitel 2: Git installieren und einrichten

Einleitung: Nachdem du nun weißt, was Git ist und warum es so nützlich ist, wird es Zeit, es auf deinem Computer zum Laufen zu bringen. Die Installation selbst ist unkompliziert, aber es gibt ein paar wichtige Einstellungen, die du direkt am Anfang vornehmen solltest – insbesondere deine Identität (Name und E-Mail), die in jedem deiner Commits gespeichert wird. Außerdem musst du sicherstellen, dass PhpStorm weiß, wo Git installiert ist, damit du später alle Versionsverwaltungs-Funktionen direkt aus deiner Entwicklungsumgebung nutzen kannst, ohne ständig zwischen verschiedenen Programmen wechseln zu müssen. Dieses Kapitel führt dich durch alle notwendigen Schritte.

Kapitel 2: Git installieren und einrichten

Git installieren und einrichten 🛠️

Die Installation von Git ist auf allen gängigen Betriebssystemen unkompliziert. Hier findest du konkrete Schritte für Windows, macOS und Linux – inklusive der Überprüfung, ob alles geklappt hat.

Installation nach Betriebssystem

Windows

  1. Installer herunterladen

    Gehe auf die offizielle Git-Website git-scm.com/downloads/win und lade die 64-Bit-Version herunter (für die meisten modernen Rechner passend).

  2. Installer ausführen

    Starte die heruntergeladene .exe-Datei. Du wirst durch einen Installationsassistenten geführt. Die Standardeinstellungen sind für Anfänger vollkommen ausreichend – du kannst also meist einfach auf „Next" klicken. Ein paar Punkte, auf die du achten kannst:

    • Default Editor: Hier kannst du z. B. Visual Studio Code oder Notepad++ wählen, falls du Vim nicht magst (Vim ist für Einsteiger oft verwirrend).
    • PATH-Einstellung: Wähle „Git from the command line and also from 3rd-party software" – so kannst du Git überall nutzen.
    • Line Ending Conversion: Die Standardoption „Checkout Windows-style, commit Unix-style" ist sinnvoll.

  3. Installation abschließen

    Klicke am Ende auf „Install" und warte, bis der Vorgang abgeschlossen ist.

macOS

Auf dem Mac hast du mehrere Möglichkeiten:

  1. Über Xcode Command Line Tools (einfachste Methode)

    Öffne das Terminal (findest du über Spotlight mit Cmd + Leertaste → „Terminal") und gib ein:

    git --version

    Falls Git noch nicht installiert ist, erscheint automatisch ein Dialog, der dich fragt, ob du die Xcode Command Line Tools installieren möchtest. Bestätige mit „Installieren" – Git ist dann dabei.

  2. Über Homebrew (falls du Homebrew bereits nutzt)

    brew install git

    Homebrew ist ein beliebter Paketmanager für macOS. Falls du ihn noch nicht hast, findest du ihn unter brew.sh.

  3. Offizieller Installer

    Du kannst auch den Installer von git-scm.com/downloads/mac herunterladen und wie unter Windows durchklicken.

Linux

Auf den meisten Linux-Distributionen ist Git entweder schon vorinstalliert oder lässt sich mit einem einzigen Befehl nachinstallieren:

💡 Tipp: Falls du unsicher bist, welche Distribution du nutzt, kannst du mit cat /etc/os-release nachsehen.

Überprüfen, ob die Installation funktioniert hat ✅

Öffne ein Terminal (unter Windows: Git Bash, PowerShell oder Eingabeaufforderung; unter macOS/Linux: Terminal) und gib folgenden Befehl ein:

git --version

Wenn alles geklappt hat, siehst du eine Ausgabe wie:

git version 2.45.0

Die genaue Versionsnummer kann variieren – wichtig ist nur, dass keine Fehlermeldung erscheint.

Erste Konfiguration nach der Installation 🔧

Bevor du Git produktiv nutzt, solltest du deinen Namen und deine E-Mail-Adresse hinterlegen. Diese Informationen werden in jedem Commit gespeichert, sodass nachvollziehbar ist, wer welche Änderung gemacht hat.

git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

📌 Hinweis: Nutze bei user.email am besten dieselbe Adresse, die du später auch bei GitHub verwendest – so werden deine Commits dort korrekt mit deinem Profil verknüpft.

Du kannst deine Einstellungen jederzeit überprüfen mit:

git config --list

Zusammenfassung

Schritt Windows macOS Linux
Installieren Installer von git-scm.com git --version (Xcode Tools) oder Homebrew apt, dnf oder pacman
Prüfen git --version git --version git --version
Konfigurieren git config --global ... git config --global ... git config --global ...

Damit ist Git einsatzbereit und du kannst mit deinem ersten Repository loslegen! 🚀

Kapitel 2: Git installieren und einrichten

Git konfigurieren: Name und E-Mail-Adresse einrichten ⚙️

Bevor du deinen ersten Commit machst, solltest du Git mitteilen, wer du bist. Das klingt vielleicht nach einer Formalität, hat aber einen sehr konkreten Grund.

Warum ist diese Konfiguration wichtig?

Jeder Commit, den du in Git erstellst, wird mit einem Autor versehen – also mit einem Namen und einer E-Mail-Adresse. Diese Informationen werden dauerhaft in der Versionshistorie gespeichert und sind für jeden sichtbar, der Zugriff auf das Repository hat.

Das ist aus mehreren Gründen relevant:

So richtest du Name und E-Mail ein

Öffne ein Terminal (unter Windows z. B. Git Bash, PowerShell oder CMD; unter macOS/Linux das normale Terminal) und führe diese beiden Befehle aus:

git config --global user.name "Dein Name"
git config --global user.email "deine.email@beispiel.de"

Ersetze dabei natürlich die Platzhalter durch deine echten Daten. Ein konkretes Beispiel:

git config --global user.name "Max Mustermann"
git config --global user.email "max.mustermann@gmail.com"

💡 Hinweis zur E-Mail: Verwende am besten dieselbe E-Mail-Adresse, die du auch bei GitHub (oder einer anderen Plattform) nutzt. So werden deine Commits korrekt zugeordnet.

Was bedeutet --global?

Die Option --global sorgt dafür, dass diese Einstellungen für alle Git-Repositories auf deinem Computer gelten. Die Konfiguration wird in einer Datei namens .gitconfig in deinem Benutzerverzeichnis gespeichert.

Falls du für ein einzelnes Projekt andere Daten verwenden möchtest (z. B. eine Firmen-E-Mail für berufliche Projekte), kannst du die Konfiguration ohne --global im jeweiligen Repository-Ordner ausführen:

git config user.name "Firmenname Max"
git config user.email "max@firma.de"

Diese lokale Einstellung überschreibt dann die globale – aber nur für dieses eine Repository.

Überprüfen, ob die Konfiguration funktioniert hat

Mit diesen Befehlen kannst du dir anzeigen lassen, was Git aktuell gespeichert hat:

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

Die Ausgabe sollte dann entsprechend dein Name und deine E-Mail sein. Alternativ kannst du dir alle globalen Einstellungen auf einmal anzeigen lassen:

git config --global --list

Was passiert, wenn du das nicht konfigurierst? 🚨

Wenn du versuchst, einen Commit zu erstellen, ohne Name und E-Mail konfiguriert zu haben, passiert Folgendes:

  1. Git verweigert den Commit und zeigt eine Fehlermeldung wie diese:

    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"

  2. Kein Commit wird erstellt, bis du die Konfiguration nachholst.

Das ist also kein stilles Problem, das später Ärger macht – Git zwingt dich förmlich dazu, diese Angaben zu machen, bevor du loslegst. Trotzdem ist es besser, das einmal sauber am Anfang zu erledigen, als bei jedem neuen Projekt darüber zu stolpern.

Zusammenfassung 📋

Befehl Wirkung
git config --global user.name "Name" Setzt deinen Namen für alle Repos
git config --global user.email "email" Setzt deine E-Mail für alle Repos
git config --global --list Zeigt alle globalen Einstellungen
git config user.name (ohne --global) Setzt den Namen nur für das aktuelle Repo

Nach dieser einmaligen Konfiguration bist du bereit für deinen ersten Commit! 🎉

Kapitel 2: Git installieren und einrichten

Git in PhpStorm einrichten und nutzen 🛠️

PhpStorm hat eine hervorragende Git-Integration, die dir erlaubt, fast alle Git-Operationen direkt in der IDE durchzuführen – ohne ständig ins Terminal wechseln zu müssen. Die Einrichtung ist in der Regel unkompliziert, da PhpStorm Git oft automatisch erkennt.

Automatische Erkennung prüfen

In den meisten Fällen findet PhpStorm deine Git-Installation von selbst, sobald Git korrekt installiert ist. Um das zu überprüfen:

  1. Öffne PhpStorm und gehe zu File → Settings (auf macOS: PhpStorm → Settings).

  2. Navigiere im linken Menü zu Version Control → Git.

  3. Im Feld Path to Git executable siehst du den Pfad, den PhpStorm verwendet. Typische Werte sind:

    • Windows: C:\Program Files\Git\bin\git.exe
    • macOS: /usr/bin/git oder /usr/local/bin/git
    • Linux: /usr/bin/git

  4. Klicke auf den Button Test neben dem Pfad. Wenn alles funktioniert, erscheint eine Meldung wie:

    „Git version 2.x.x" ✅

Falls PhpStorm Git nicht automatisch findet, musst du den Pfad manuell angeben.

Git-Pfad manuell konfigurieren

Sollte der Test fehlschlagen oder das Feld leer sein, kannst du den Pfad selbst eintragen:

  1. Git-Pfad herausfinden – Öffne ein Terminal (oder die Eingabeaufforderung unter Windows) und gib ein:

    # Windows (Git Bash oder CMD)
where git

# macOS / Linux
which git

    Die Ausgabe zeigt dir den vollständigen Pfad zur Git-Executable.

  2. Pfad in PhpStorm eintragen – Kopiere den Pfad und füge ihn in das Feld Path to Git executable ein. Unter Windows achte darauf, dass du auf git.exe im bin-Ordner verweist (nicht auf git.cmd).

  3. Erneut testen – Klicke wieder auf Test, um sicherzustellen, dass die Verbindung funktioniert.

Erste Schritte mit Git in PhpStorm

Sobald Git erkannt wird, stehen dir viele praktische Funktionen zur Verfügung:

Häufige Probleme und Lösungen

Problem Mögliche Ursache Lösung
„Git is not installed" Git nicht installiert oder Pfad falsch Git installieren und Pfad manuell setzen
Test zeigt Fehler trotz korrektem Pfad Falsches Binary gewählt (z. B. git.cmd statt git.exe) Pfad auf .../bin/git.exe korrigieren
Git-Funktionen ausgegraut Projekt ist kein Git-Repository Repository initialisieren oder klonen
Commit-Button fehlt Tool-Window nicht sichtbar View → Tool Windows → Commit aktivieren

💡 Tipp: Nach einer Neuinstallation von Git solltest du PhpStorm einmal neu starten, damit die Änderungen sicher erkannt werden.

Zusammenfassung

Die Git-Integration in PhpStorm einzurichten ist meistens eine Sache von wenigen Klicks: Settings → Version Control → Git → Test. Sobald der Test erfolgreich ist, kannst du Commits, Branches, Merges und vieles mehr direkt in der IDE erledigen – bequem und ohne Kontextwechsel. 🎉

Kapitel 3: Das erste Repository erstellen

Einleitung: Jetzt wird es praktisch! Ein „Repository" (kurz: Repo) ist im Grunde dein Projekt-Ordner, der von Git überwacht wird. Sobald du einen Ordner in ein Repository verwandelst, beginnt Git damit, alle Änderungen zu tracken. Dabei ist es wichtig zu verstehen, dass Git nicht einfach alles automatisch speichert – du entscheidest bewusst, welche Änderungen aufgezeichnet werden sollen. Außerdem lernst du die .gitignore-Datei kennen, mit der du Git sagst, welche Dateien es ignorieren soll (zum Beispiel temporäre Dateien oder sensible Konfigurationsdaten). Dieses Kapitel vermittelt dir das Verständnis für Gits dreistufiges System aus Working Directory, Staging Area und Repository.

Kapitel 3: Das erste Repository erstellen

Ein bestehendes Projekt in PhpStorm zum Git-Repository machen 🚀

Du hast also schon einen Projektordner mit PHP-Dateien und möchtest jetzt anfangen, Git dafür zu nutzen. Das ist ein sehr häufiger Anwendungsfall – und PhpStorm macht es dir dabei besonders leicht.

Schritt-für-Schritt-Anleitung

  1. Projekt in PhpStorm öffnen

    Falls noch nicht geschehen, öffne dein bestehendes Projekt über File → Open und wähle den Projektordner aus.

  2. Git-Repository initialisieren

    Gehe im Menü auf VCS → Enable Version Control Integration… (alternativ findest du es manchmal unter Git → Enable Version Control Integration…, je nach PhpStorm-Version).

    Es öffnet sich ein kleines Dialogfenster, in dem du das Versionskontrollsystem auswählen kannst. Wähle Git aus und bestätige mit OK.

  3. Änderungen im Interface beobachten

    Nach der Initialisierung passieren sofort sichtbare Dinge:

    • Die Dateinamen in der Projektansicht werden rot eingefärbt – das bedeutet, dass diese Dateien noch nicht von Git „getrackt" werden (also noch nicht zur Versionskontrolle hinzugefügt wurden).
    • Unten in PhpStorm erscheint ein neuer Reiter namens Git (neben „Terminal", „Problems" usw.), über den du später Commits, Branches und die Historie verwalten kannst.
    • Das Menü VCS wird teilweise durch Git ersetzt oder erweitert.

  4. Dateien zur Staging Area hinzufügen

    Damit Git deine Dateien überhaupt „kennt", musst du sie stagen. Du kannst:

    • Im Projektbaum mit Rechtsklick auf eine Datei oder einen Ordner gehen und Git → Add wählen.
    • Oder einfach alle Dateien auf einmal hinzufügen: Rechtsklick auf den Projektstammordner → Git → Add.

    Die Dateien wechseln ihre Farbe von rot zu grün – das zeigt an, dass sie jetzt in der Staging Area liegen und beim nächsten Commit berücksichtigt werden.

  5. Ersten Commit erstellen

    Jetzt ist der perfekte Moment für deinen Initial Commit:

    • Drücke Ctrl + K (Windows/Linux) oder Cmd + K (macOS) – oder gehe über Git → Commit…
    • Es öffnet sich das Commit-Fenster. Hier siehst du alle gestagten Dateien.
    • Gib eine Commit-Message ein, z. B.: Initial commit: Projektstruktur hinzugefügt
    • Klicke auf Commit.

    💡 Tipp: Beim ersten Commit ist es üblich, eine kurze, beschreibende Nachricht wie „Initial commit" zu verwenden. Später solltest du aussagekräftigere Messages schreiben.

Was passiert dabei im Hintergrund? 🔍

Auch wenn PhpStorm dir die Arbeit abnimmt, laufen im Hintergrund ganz normale Git-Befehle ab. Hier die Entsprechung zu den Schritten oben:

PhpStorm-Aktion Git-Befehl im Terminal
„Enable Version Control Integration" mit Git git init
Dateien per „Git → Add" hinzufügen git add <datei> oder git add .
Commit erstellen git commit -m "Nachricht"

Der versteckte .git-Ordner

Sobald du Git initialisierst, erstellt Git einen versteckten Ordner namens .git im Wurzelverzeichnis deines Projekts. Dieser Ordner enthält:

⚠️ Wichtig: Lösche diesen Ordner niemals manuell, sonst verlierst du deine gesamte Git-Historie!

Du kannst den Ordner sehen, wenn du in deinem Dateimanager versteckte Dateien anzeigen lässt oder im Terminal ls -la (macOS/Linux) bzw. dir /a (Windows) eingibst.

Die drei Zustände deiner Dateien – visualisiert

Nach der Initialisierung befinden sich deine Dateien zunächst nur im Working Directory. Durch das Hinzufügen wandern sie in die Staging Area, und erst durch den Commit landen sie im Repository:

flowchart LR
    A["📂 Working Directory<br>„Deine Dateien auf der Festplatte“"]
    B["📋 Staging Area<br>„Vorgemerkt für den nächsten Commit“"]
    C["🗄️ Repository<br>„Dauerhaft gespeicherte Versionen“"]

    A -->|"git add<br>„Git → Add“ in PhpStorm"| B
    B -->|"git commit<br>„Commit“ in PhpStorm"| C

Was du jetzt hast

Nach diesen Schritten ist dein Projekt ein vollwertiges lokales Git-Repository. Du kannst ab sofort:

Das Repository liegt aktuell nur lokal auf deinem Computer. Wenn du es später auf GitHub hochladen möchtest, um ein Backup zu haben oder mit anderen zusammenzuarbeiten, ist das ein separater Schritt – aber die Grundlage dafür hast du jetzt geschaffen. 🎉

Kapitel 3: Das erste Repository erstellen

Die .gitignore-Datei – was sie ist und warum du sie brauchst 🚫

Wenn du mit Git arbeitest, möchtest du nicht jede Datei in deinem Projektordner auch tatsächlich versionieren. Manche Dateien sind temporär, automatisch generiert oder enthalten sensible Informationen – sie gehören schlicht nicht ins Repository. Genau hier kommt die .gitignore-Datei ins Spiel.

Was ist die .gitignore-Datei?

Die .gitignore ist eine einfache Textdatei im Hauptverzeichnis deines Git-Repositories. Sie enthält eine Liste von Dateinamen, Ordnern oder Mustern, die Git ignorieren soll. Das bedeutet: Dateien, die auf diese Muster passen, werden von Git nicht getrackt – sie tauchen nicht in der Staging Area auf, werden nicht committet und landen somit auch nicht auf GitHub oder in deiner Versionshistorie.

💡 Die Datei heißt wirklich .gitignore (mit Punkt am Anfang, ohne Dateiendung). Unter Windows kann das Erstellen einer solchen Datei manchmal etwas umständlich sein – in PhpStorm kannst du sie aber problemlos über Rechtsklick → New → File anlegen.

Warum ist das wichtig?

Es gibt mehrere gute Gründe, bestimmte Dateien nicht ins Repository aufzunehmen:

  1. Abhängigkeiten und generierte Dateien

    Ordner wie vendor/ (Composer) oder node_modules/ (npm) können tausende Dateien enthalten und viele hundert Megabyte groß werden. Diese Dateien werden durch composer install bzw. npm install automatisch aus den Paketquellen heruntergeladen – sie müssen also nicht versioniert werden. Die Konfigurationsdateien (composer.json, package.json) reichen völlig aus, um die Abhängigkeiten jederzeit wiederherzustellen.

  2. Sensible Daten

    Dateien wie .env enthalten oft Passwörter, API-Schlüssel oder Datenbank-Zugangsdaten. Wenn du diese ins Repository eincheckst und auf GitHub pushst, sind sie unter Umständen öffentlich sichtbar – ein erhebliches Sicherheitsrisiko.

  3. IDE- und systemspezifische Dateien

    PhpStorm speichert Projekteinstellungen im Ordner .idea/. Dein Betriebssystem legt möglicherweise Dateien wie .DS_Store (macOS) oder Thumbs.db (Windows) an. Diese Dateien sind nur für dich lokal relevant und würden bei anderen Teammitgliedern im besten Fall nur stören – im schlimmsten Fall Konflikte verursachen.

  4. Temporäre und Cache-Dateien

    Logs, Caches und temporäre Dateien ändern sich ständig und haben keinen Mehrwert in der Versionshistorie. Sie würden nur die Historie „verschmutzen" und das Repository unnötig aufblähen.

Beispiel-.gitignore für ein PHP-Projekt

Hier ist eine praxisnahe .gitignore-Datei, wie du sie für ein typisches PHP-Projekt mit Composer und eventuell Node.js-basierten Build-Tools (z. B. für Frontend-Assets) verwenden könntest:

# ===========================================
# Abhängigkeiten (werden über Paketmanager installiert)
# ===========================================

# Composer-Abhängigkeiten
/vendor/

# Node.js-Abhängigkeiten (falls du npm/Yarn für Frontend-Tools nutzt)
/node_modules/


# ===========================================
# Umgebungs- und Konfigurationsdateien mit sensiblen Daten
# ===========================================

# Umgebungsvariablen (Passwörter, API-Keys, DB-Zugangsdaten)
.env
.env.local
.env.*.local


# ===========================================
# IDE- und Editor-Einstellungen
# ===========================================

# PhpStorm / JetBrains IDEs
/.idea/

# Visual Studio Code
/.vscode/


# ===========================================
# Betriebssystem-spezifische Dateien
# ===========================================

# macOS
.DS_Store

# Windows
Thumbs.db
Desktop.ini


# ===========================================
# Logs, Caches und temporäre Dateien
# ===========================================

# Allgemeine Log-Dateien
*.log

# Composer-Cache (normalerweise global, aber sicherheitshalber)
/composer.phar

# PHP-Cache-Dateien (z. B. von Frameworks wie Laravel oder Symfony)
/storage/logs/
/storage/framework/cache/
/storage/framework/sessions/
/storage/framework/views/
/bootstrap/cache/

# Build-Artefakte (falls du Frontend-Assets kompilierst)
/public/build/
/public/hot
/public/mix-manifest.json


# ===========================================
# Tests und Coverage-Reports
# ===========================================

# PHPUnit Coverage-Reports
/coverage/
.phpunit.result.cache

Erklärung der wichtigsten Einträge

Eintrag Bedeutung
/vendor/ Schließt den kompletten Composer-Abhängigkeitsordner aus. Der führende Slash / bedeutet: nur im Hauptverzeichnis.
/node_modules/ Dasselbe für npm/Yarn-Pakete. Kann bei Frontend-Projekten leicht mehrere zehntausend Dateien enthalten.
.env Umgebungsdatei mit sensiblen Konfigurationswerten – niemals ins Repository!
/.idea/ PhpStorm speichert hier Projekteinstellungen, die nur lokal relevant sind.
.DS_Store Versteckte macOS-Systemdatei, die Finder-Einstellungen speichert.
*.log Alle Dateien mit der Endung .log – also sämtliche Log-Dateien im gesamten Projekt.
/storage/ und /bootstrap/cache/ Typische Cache-Verzeichnisse bei Laravel-Projekten.

Wie lege ich die Datei in PhpStorm an?

  1. Rechtsklick auf das Projektstammverzeichnis im Projektbaum (links in PhpStorm).
  2. Wähle New → File und gib als Namen .gitignore ein.
  3. Füge die gewünschten Einträge ein und speichere die Datei.
  4. Committe die .gitignore-Datei selbst – sie gehört ins Repository, damit alle Teammitglieder (oder du selbst auf anderen Rechnern) dieselben Regeln haben.

⚠️ Wichtig: Wenn du eine Datei bereits committet hast und sie danach zur .gitignore hinzufügst, wird Git sie trotzdem weiter tracken. Du musst sie erst aus dem Index entfernen:

git rm --cached dateiname

Das entfernt die Datei aus dem Repository, lässt sie aber lokal auf deiner Festplatte bestehen.

Fazit ✅

Die .gitignore-Datei ist ein unverzichtbares Werkzeug für saubere Git-Repositories. Sie sorgt dafür, dass nur relevanter Code und Konfiguration versioniert wird – ohne unnötigen Ballast, ohne Sicherheitsrisiken und ohne Konflikte durch nutzerspezifische Dateien. Nimm dir zu Beginn jedes Projekts kurz Zeit, eine sinnvolle .gitignore anzulegen – dein zukünftiges Ich wird es dir danken. 😊

Kapitel 3: Das erste Repository erstellen

Die drei Bereiche in Git: Working Directory, Staging Area und Repository 📂

Wenn du zum ersten Mal mit Git arbeitest, fragst du dich vielleicht, warum das Speichern von Änderungen so „kompliziert" ist. Statt einfach auf „Speichern" zu klicken, musst du Dateien erst stagen und dann committen. Das wirkt anfangs umständlich – hat aber sehr gute Gründe, die dir mit der Zeit enorm helfen werden.

Die drei Bereiche im Überblick

Git organisiert dein Projekt in drei logische Bereiche, die jeweils eine bestimmte Rolle spielen:

flowchart LR
    WD["🗂️ Working Directory\nDein Arbeitsordner"]
    SA["📋 Staging Area\nVorbereitungsbereich"]
    REPO["📦 Repository\nDie Versionshistorie"]
    
    WD -->|git add| SA
    SA -->|git commit| REPO
    REPO -->|git checkout| WD

1. Working Directory – dein Arbeitsordner

Das Working Directory ist schlicht der Ordner auf deiner Festplatte, in dem du arbeitest. Hier liegen alle Dateien deines Projekts so, wie du sie gerade siehst und bearbeitest. Wenn du eine PHP-Datei öffnest, etwas änderst und speicherst (im klassischen Sinne mit Strg+S), dann ist diese Änderung nur im Working Directory – Git weiß davon noch nichts Besonderes.

💡 Merke: Das Working Directory ist der „echte" Zustand deiner Dateien, so wie du sie gerade auf dem Bildschirm siehst.

2. Staging Area – der Vorbereitungsbereich

Die Staging Area (manchmal auch Index genannt) ist ein Zwischenbereich, in dem du auswählst, welche Änderungen in den nächsten Commit kommen sollen. Du kannst sie dir wie einen Einkaufswagen vorstellen: Du legst Dinge hinein, aber erst an der Kasse (beim Commit) wird wirklich „abgerechnet".

Mit dem Befehl git add datei.php (oder in PhpStorm per Rechtsklick → Git → Add) verschiebst du eine Änderung vom Working Directory in die Staging Area. Die Datei ist damit vorgemerkt, aber noch nicht dauerhaft gespeichert.

💡 Merke: Die Staging Area gibt dir die Kontrolle darüber, was genau in einem Commit landet – nicht einfach „alles, was ich geändert habe".

3. Repository – die Versionshistorie

Das Repository (genauer: das lokale Repository) ist die eigentliche Git-Datenbank. Hier werden alle Commits gespeichert – also alle „Schnappschüsse" deines Projekts mit Autor, Zeitstempel und einer Nachricht. Sobald du git commit ausführst, wandern die Änderungen aus der Staging Area ins Repository und werden dauerhaft Teil der Versionsgeschichte.

Das Repository liegt im versteckten Ordner .git in deinem Projektverzeichnis. Du arbeitest normalerweise nicht direkt damit, sondern über Git-Befehle.

💡 Merke: Das Repository ist das „Gedächtnis" deines Projekts – hier kannst du jederzeit zu früheren Zuständen zurückkehren.

Warum nicht einfach „speichern"? 🤔

Die Dreiteilung mag auf den ersten Blick übertrieben wirken, aber sie löst mehrere echte Probleme:

  1. Gezielte Commits statt „alles auf einmal"

    Stell dir vor, du hast an drei verschiedenen Dingen gleichzeitig gearbeitet: einem Bugfix, einem neuen Feature und einer kleinen Textkorrektur. Ohne Staging Area müsstest du alles zusammen in einem Commit speichern – oder umständlich Dateien hin- und herkopieren. Mit der Staging Area kannst du gezielt auswählen: Erst den Bugfix committen, dann das Feature, dann die Textkorrektur. So bleibt deine Historie sauber und nachvollziehbar.

  2. Überprüfen vor dem Festschreiben

    Die Staging Area gibt dir einen Moment zum Innehalten. Du kannst mit git status oder in PhpStorm im Commit-Fenster genau sehen, welche Änderungen du gleich committen wirst. Das verhindert, dass versehentlich Debug-Code, temporäre Dateien oder unfertige Änderungen in die Versionshistorie gelangen.

  3. Teilweises Stagen möglich

    Du kannst sogar Teile einer Datei stagen (sogenanntes „partial staging" oder „hunks"). Wenn du in einer Datei zwei unabhängige Änderungen gemacht hast, kannst du nur eine davon in den nächsten Commit aufnehmen. Das ist mit einem einfachen „Speichern"-Konzept nicht möglich.

  4. Sicherheit und Flexibilität

    Solange Änderungen nur im Working Directory sind, kannst du sie jederzeit verwerfen. Solange sie nur in der Staging Area sind, kannst du sie wieder „unstagen". Erst wenn sie im Repository sind, sind sie dauerhaft (und selbst dann kannst du mit Git noch einiges korrigieren, aber das ist ein Thema für später).

Ein praktisches Beispiel

Angenommen, du arbeitest an einer Website und hast folgende Änderungen gemacht:

Ohne Staging Area würdest du alle drei Dateien auf einmal committen – inklusive des Passworts. 😬

Mit Staging Area machst du Folgendes:

git add index.php
git add style.css
# config.php wird NICHT hinzugefügt!
git commit -m "Kontaktformular und Farbänderungen hinzugefügt"

Du hast volle Kontrolle darüber, was ins Repository kommt. Das Passwort bleibt draußen, du kannst es in Ruhe korrigieren und später separat committen (oder die Datei in die .gitignore aufnehmen).

Zusammenfassung als Tabelle

Bereich Was ist das? Git-Befehl zum Wechsel
Working Directory Dein Projektordner mit allen aktuellen Dateien –
Staging Area Vorbereitungsbereich für den nächsten Commit git add
Repository Dauerhafte Versionshistorie aller Commits git commit

Fazit ✨

Die drei Bereiche in Git sind kein unnötiger Overhead, sondern ein durchdachtes System, das dir erlaubt:

Sobald du dich daran gewöhnt hast, wirst du die Staging Area als eines der nützlichsten Features von Git schätzen lernen. In PhpStorm siehst du diese drei Bereiche übrigens sehr anschaulich im Commit-Fenster: Links die geänderten Dateien (Working Directory), in der Mitte die zum Commit vorgemerkten (Staging Area), und nach dem Commit landen sie in der Historie (Repository). 🚀

Kapitel 4: Commits erstellen und verstehen

Einleitung: Commits sind das Herzstück von Git – sie sind die „Speicherpunkte" deines Projekts. Jeder Commit ist ein Schnappschuss deines gesamten Projekts zu einem bestimmten Zeitpunkt, versehen mit einer Nachricht, die beschreibt, was du geändert hast. Die Kunst besteht darin, sinnvolle Commits zu erstellen: nicht zu groß (damit sie übersichtlich bleiben), nicht zu klein (damit sie bedeutsam sind), und mit klaren Nachrichten versehen. In diesem Kapitel lernst du nicht nur, wie du Commits erstellst, sondern auch, wie du sie nachträglich korrigieren kannst, falls dir ein Fehler unterläuft. PhpStorm bietet dafür eine sehr komfortable Oberfläche, die den Prozess deutlich vereinfacht.

Kapitel 4: Commits erstellen und verstehen

Dein erster Commit in PhpStorm – Schritt für Schritt 🎉

Du hast dein Projekt als Git-Repository initialisiert und möglicherweise schon eine .gitignore-Datei angelegt. Jetzt wird es Zeit, deinen ersten Commit zu machen – also einen Schnappschuss deines aktuellen Projektstands in der Git-Historie zu speichern.

Der Ablauf im Überblick

Bevor wir in die Details gehen, hier der grundsätzliche Prozess:

flowchart LR
    A["1. Dateien bearbeiten\nim Working Directory"] --> B["2. Dateien zur\nStaging Area hinzufuegen"]
    B --> C["3. Commit erstellen\nmit Nachricht"]
    C --> D["4. Aenderung ist\nin der Historie"]

In PhpStorm ist dieser Prozess besonders komfortabel, weil du alles in einer einzigen Oberfläche erledigen kannst.

Schritt-für-Schritt-Anleitung

  1. Das Commit-Fenster öffnen

    Es gibt mehrere Wege, das Commit-Fenster zu öffnen:

    • Tastenkürzel: Strg + K (Windows/Linux) bzw. Cmd + K (macOS) – der schnellste Weg
    • Menü: Gehe zu Git → Commit…
    • Toolbar: Klicke auf das grüne Häkchen-Symbol in der oberen Symbolleiste

    Es öffnet sich links (oder als separates Fenster, je nach Einstellung) das Commit-Tool-Window.

  2. Dateien für den Commit auswählen

    Im Commit-Fenster siehst du eine Liste aller Dateien, die sich seit dem letzten Commit geändert haben. Diese sind in Kategorien unterteilt:

    • Unversioned Files: Neue Dateien, die Git noch nicht kennt (rot markiert)
    • Modified Files: Bereits getrackte Dateien, die du verändert hast (blau markiert)
    • Deleted Files: Dateien, die gelöscht wurden

    💡 Tipp: Bei deinem allerersten Commit werden alle Dateien als „Unversioned" angezeigt, weil Git sie noch nie gesehen hat.

    So wählst du Dateien aus:

    • Setze ein Häkchen vor jede Datei, die du in diesen Commit aufnehmen möchtest
    • Um alle Dateien auszuwählen, klicke auf das Häkchen ganz oben bei „Changes" oder „Unversioned Files"
    • Du kannst auch einzelne Dateien gezielt ein- oder ausschließen

    PhpStorm zeigt dir bei jeder Datei eine Vorschau der Änderungen (Diff), wenn du sie anklickst. So kannst du nochmal prüfen, was genau du committen wirst.

  3. Eine aussagekräftige Commit-Nachricht schreiben

    Unterhalb der Dateiliste findest du ein Textfeld mit dem Platzhalter „Commit Message". Hier beschreibst du, was du geändert hast und warum.

    Für deinen ersten Commit ist eine einfache Nachricht völlig in Ordnung, zum Beispiel:

    Initial commit: Projektstruktur angelegt

    oder etwas ausführlicher:

    Erstes Commit: Grundlegende PHP-Dateien und Konfiguration hinzugefügt

    📝 Best Practice: Schreibe die Nachricht so, dass du (oder andere) in drei Monaten noch verstehst, was dieser Commit enthält. Mehr dazu später im Kurs bei den Best Practices.

  4. Optionale Einstellungen prüfen

    Unter dem Nachrichtenfeld findest du einige Optionen, die du für den Anfang meist ignorieren kannst:

    • Amend commit: Fügt Änderungen zum letzten Commit hinzu (für Anfänger erstmal nicht relevant)
    • Author: Zeigt deinen konfigurierten Namen und E-Mail – sollte bereits korrekt sein
    • Before Commit: Hier kannst du automatische Prüfungen aktivieren (z. B. Code-Analyse, Reformatierung)

    Für deinen ersten Commit kannst du diese Optionen auf den Standardeinstellungen belassen.

  5. Den Commit abschließen

    Wenn du mit deiner Dateiauswahl und Nachricht zufrieden bist, klicke auf den Commit-Button unten im Fenster.

    ⚠️ Hinweis: Du siehst möglicherweise auch einen Button „Commit and Push". Dieser würde den Commit direkt auf einen Remote-Server (z. B. GitHub) hochladen. Da du noch kein Remote-Repository eingerichtet hast, wähle zunächst nur „Commit".

    PhpStorm zeigt dir kurz eine Bestätigung an, z. B.:

    1 file committed: Initial commit: Projektstruktur angelegt

Nach dem Commit: Überprüfen, ob alles geklappt hat

Um sicherzugehen, dass dein Commit erfolgreich war, kannst du die Git-Historie in PhpStorm öffnen:

Zusammenfassung des Prozesses

Schritt Aktion Tastenkürzel
Commit-Fenster öffnen Git → Commit… Strg/Cmd + K
Dateien auswählen Häkchen setzen –
Nachricht schreiben Im Textfeld eingeben –
Commit abschließen Auf „Commit" klicken –
Historie prüfen Git → Show Git Log Alt + 9

Was passiert eigentlich im Hintergrund? 🔍

Wenn du in PhpStorm auf „Commit" klickst, führt PhpStorm im Hintergrund zwei Git-Befehle aus:

git add <ausgewählte-dateien>
git commit -m "Deine Commit-Nachricht"

Der erste Befehl verschiebt die Dateien in die Staging Area, der zweite erstellt den eigentlichen Commit im Repository. PhpStorm fasst diese beiden Schritte für dich zusammen, sodass du sie nicht einzeln ausführen musst – aber es ist gut zu wissen, was „unter der Haube" passiert.

Du hast jetzt deinen ersten Commit erstellt! 🎊 Ab jetzt kannst du jederzeit weitere Änderungen machen und neue Commits erstellen – und dabei immer auf frühere Versionen zurückgreifen, falls nötig.

Kapitel 4: Commits erstellen und verstehen

Gute Commit-Nachrichten schreiben ✍️

Eine Commit-Nachricht ist mehr als nur eine Pflichtübung – sie ist Dokumentation für dein zukünftiges Ich und für jeden, der jemals mit deinem Code arbeiten wird. Schlecht formulierte Nachrichten machen die Git-Historie unbrauchbar, während gute Nachrichten dir helfen, Änderungen schnell zu verstehen, Fehler zu finden und den Projektverlauf nachzuvollziehen.

Warum sind gute Commit-Nachrichten so wichtig?

Stell dir vor, du suchst in drei Monaten einen Bug und schaust in deine Git-Historie. Du siehst Folgendes:

fix
update
asdf
done
nochmal gefixt

Das hilft dir überhaupt nicht. Du musst jeden Commit einzeln öffnen und den Code-Diff analysieren, um zu verstehen, was passiert ist. Bei einer sauberen Historie hingegen siehst du sofort:

Benutzer-Login: Passwort-Validierung hinzugefügt
Kontaktformular: E-Mail-Versand bei leeren Feldern verhindert
Navigation: Dropdown-Menü schließt sich jetzt bei Klick außerhalb

Hier erkennst du auf einen Blick, was jeder Commit bewirkt – ohne den Code überhaupt anzuschauen.

Die wichtigsten Regeln für Commit-Nachrichten

1. Verwende eine aussagekräftige Betreffzeile

Die erste Zeile deiner Commit-Nachricht ist die Betreffzeile – sie wird in Listen, Logs und Übersichten angezeigt. Sie sollte:

💡 Tipp: Vervollständige gedanklich den Satz: „Wenn dieser Commit angewendet wird, wird er…" – und dann kommt deine Betreffzeile.

2. Trenne Betreff und Beschreibung durch eine Leerzeile

Wenn du mehr Details hinzufügen möchtest, lässt du nach der Betreffzeile eine leere Zeile und schreibst dann einen ausführlicheren Text. Viele Tools (auch PhpStorm und GitHub) behandeln die erste Zeile speziell – sie wird als Überschrift angezeigt.

3. Erkläre das „Warum", nicht nur das „Was"

Der Code zeigt, was geändert wurde. Die Commit-Nachricht sollte erklären, warum du diese Änderung gemacht hast – besonders wenn es nicht offensichtlich ist.

4. Halte dich an eine konsistente Sprache

Entscheide dich für eine Sprache (Deutsch oder Englisch) und bleibe dabei. In der Open-Source-Welt und bei internationalen Teams ist Englisch Standard, aber für persönliche oder deutschsprachige Teamprojekte ist Deutsch völlig in Ordnung.

Beispiele: Schlechte vs. gute Commit-Nachrichten

❌ Schlechte Beispiele

Nachricht Problem
fix Was wurde gefixt? Wo? Warum?
update Extrem nichtssagend – jeder Commit ist ein „Update"
asdf / test / wip Keine Information, wirkt unprofessionell
Änderungen gemacht Offensichtlich – aber welche Änderungen?
Bug gefixt in der Datei login.php Zeile 47 wo die Variable falsch war Zu lang, zu viele Details, die sich ändern können
Login Zu vage – was ist mit dem Login?

✅ Gute Beispiele

Nachricht Warum gut?
Passwort-Validierung bei Login hinzugefügt Klar, spezifisch, sagt was passiert
404-Fehler bei nicht existierenden Produktseiten behoben Beschreibt das Problem und die Lösung
Bootstrap 5 auf Version 5.3 aktualisiert Konkret und nachvollziehbar
Kontaktformular: Pflichtfeld-Prüfung für E-Mail ergänzt Nutzt Präfix zur Kategorisierung
Performance: Datenbankabfragen in Produktliste optimiert Gibt Kontext durch Kategorie

Eine bewährte Struktur für Commit-Nachrichten

Für einfache Änderungen reicht eine einzelne Zeile. Bei komplexeren Commits empfiehlt sich dieses Format:

Kurze Zusammenfassung im Imperativ (max. 50-72 Zeichen)

Optionaler ausführlicher Text, der erklärt:
- WARUM diese Änderung nötig war
- Was der Kontext ist
- Welche Entscheidungen getroffen wurden

Falls relevant: Referenzen zu Issues, Tickets o.ä.

Konkretes Beispiel:

Warenkorb: Mengenänderung aktualisiert jetzt den Gesamtpreis

Bisher wurde der Gesamtpreis im Warenkorb erst nach einem 
Seiten-Reload aktualisiert, wenn der Nutzer die Menge eines 
Produkts geändert hat. Das war verwirrend und führte zu 
Support-Anfragen.

Die Lösung nutzt einen AJAX-Request, der bei jeder 
Mengenänderung den neuen Preis vom Server holt und 
das DOM aktualisiert.

Praktische Konventionen und Präfixe

Viele Teams nutzen Präfixe, um Commits zu kategorisieren. Das ist besonders hilfreich, wenn du später die Historie filterst oder durchsuchst. Hier eine einfache Variante, die auch für Solo-Projekte gut funktioniert:

Präfix Verwendung Beispiel
Feature: Neue Funktionalität Feature: Benutzer können Profilbild hochladen
Fix: Fehlerbehebung Fix: Login-Button reagiert wieder auf mobilen Geräten
Refactor: Code-Verbesserung ohne neue Funktion Refactor: Datenbank-Klasse in separate Datei ausgelagert
Style: Optische Änderungen, Formatierung Style: Einheitliche Einrückung in allen PHP-Dateien
Docs: Dokumentation Docs: README um Installationsanleitung erweitert
Chore: Wartung, Dependencies Chore: Composer-Pakete aktualisiert

📌 Hinweis: Diese Präfixe sind Konventionen, keine festen Regeln. Wichtig ist, dass du konsistent bleibst – entweder immer Präfixe nutzen oder nie.

Commit-Nachrichten in PhpStorm schreiben

In PhpStorm hast du beim Commit-Dialog ein Textfeld für die Nachricht. Ein paar Tipps speziell für PhpStorm:

Zusammenfassung: Die goldenen Regeln 📋

  1. Schreibe im Imperativ – „Füge hinzu", nicht „Hinzugefügt" oder „Fügt hinzu"
  2. Halte die Betreffzeile kurz – maximal 50–72 Zeichen
  3. Sei spezifisch – „Login-Validierung" statt „Update"
  4. Erkläre das Warum – besonders bei nicht offensichtlichen Änderungen
  5. Ein Commit = eine logische Änderung – nicht drei verschiedene Dinge in einem Commit mischen
  6. Bleibe konsistent – gleiche Sprache, gleiche Konventionen im ganzen Projekt

Eine gute Commit-Historie ist wie ein gut geführtes Logbuch: Sie erzählt die Geschichte deines Projekts und hilft dir, auch nach Monaten noch zu verstehen, warum du bestimmte Entscheidungen getroffen hast. 🚀

Kapitel 4: Commits erstellen und verstehen

Die Git-Historie in PhpStorm anzeigen und verstehen 🔍

Nachdem du einige Commits gemacht hast, möchtest du natürlich auch nachschauen können, was du wann geändert hast. PhpStorm bietet dafür ein mächtiges, visuell ansprechendes Werkzeug: das Git Log. Hier erfährst du, wie du es nutzt und die Informationen richtig interpretierst.

Das Git-Log-Fenster öffnen

Es gibt mehrere Wege, um zur Commit-Historie zu gelangen:

  1. Über das Menü: Gehe zu Git → Show Git Log (oder in älteren Versionen VCS → Git → Show History).

  2. Über das Tool-Fenster: Am unteren Rand von PhpStorm findest du den Reiter Git. Klicke darauf, und du siehst automatisch den Log-Tab.

  3. Tastenkombination: Mit Alt + 9 (Windows/Linux) bzw. Cmd + 9 (macOS) öffnest du das Git-Tool-Fenster direkt.

Das Log-Fenster zeigt dir eine chronologische Liste aller Commits – die neuesten oben, die ältesten unten.

Die Ansicht verstehen

Das Git-Log in PhpStorm ist in mehrere Bereiche aufgeteilt:

flowchart TB
    subgraph LOG["Git Log Fenster"]
        A["Commit-Liste\nalle Commits chronologisch"] --> B["Commit-Details\nNachricht, Autor, Datum"]
        B --> C["Geaenderte Dateien\nListe der betroffenen Files"]
        C --> D["Diff-Ansicht\nkonkrete Aenderungen im Code"]
    end

Die Commit-Liste (linker/oberer Bereich)

Hier siehst du für jeden Commit:

💡 Tipp: Die grafische Darstellung links neben den Commits zeigt dir die Branch-Struktur – also wo Branches abzweigen und wieder zusammengeführt werden.

Die Commit-Details (mittlerer Bereich)

Wenn du einen Commit in der Liste anklickst, siehst du rechts daneben oder darunter:

Die geänderten Dateien

Unterhalb der Commit-Details findest du eine Liste aller Dateien, die in diesem Commit geändert wurden. Jede Datei hat ein Symbol, das die Art der Änderung anzeigt:

Symbol/Farbe Bedeutung
🟢 Grün / + Datei wurde neu hinzugefügt
🔵 Blau / ~ Datei wurde geändert
🔴 Rot / - Datei wurde gelöscht
🟣 Lila Datei wurde umbenannt oder verschoben

Die konkreten Änderungen ansehen (Diff)

Das eigentlich Spannende ist natürlich: Was genau wurde geändert? Dafür nutzt du die Diff-Ansicht:

  1. Datei auswählen: Klicke in der Liste der geänderten Dateien auf eine Datei.

  2. Diff öffnen: Doppelklicke auf die Datei oder drücke Strg + D (Windows/Linux) bzw. Cmd + D (macOS).

  3. Änderungen lesen: PhpStorm zeigt dir eine Side-by-Side-Ansicht:

    • Links: Der alte Stand (vor dem Commit)
    • Rechts: Der neue Stand (nach dem Commit)

    Gelöschte Zeilen sind rot markiert, hinzugefügte grün. So siehst du auf einen Blick, was sich geändert hat.

💡 Tipp: Du kannst die Ansicht auch auf „Unified" umstellen, wenn du lieber alles untereinander statt nebeneinander sehen möchtest. Das geht über das Zahnrad-Symbol in der Diff-Ansicht.

Nützliche Filter und Suchfunktionen

Bei größeren Projekten wird die Historie schnell lang. PhpStorm bietet dir praktische Filter, um den Überblick zu behalten:

Historie einer einzelnen Datei anzeigen

Manchmal interessiert dich nicht die gesamte Projekt-Historie, sondern nur: Was ist mit dieser einen Datei passiert?

  1. Rechtsklicke auf die Datei im Projektbaum.
  2. Wähle Git → Show History.
  3. Du siehst jetzt nur die Commits, die diese Datei betreffen.

Noch detaillierter wird es mit Annotate (auch „Blame" genannt):

  1. Öffne die Datei im Editor.
  2. Rechtsklicke in den linken Rand (wo die Zeilennummern stehen).
  3. Wähle Annotate with Git Blame.

Jetzt siehst du für jede Zeile, in welchem Commit sie zuletzt geändert wurde, von wem und wann. Das ist unglaublich praktisch, um herauszufinden, wann und warum eine bestimmte Code-Stelle entstanden ist.

Praktisches Beispiel

Angenommen, du hast in den letzten Tagen mehrere Commits gemacht und möchtest nachschauen, wann du die Datei database.php zuletzt geändert hast:

  1. Öffne das Git-Log mit Alt + 9.
  2. Gib im Suchfeld oben database.php ein oder nutze den Pfad-Filter.
  3. Du siehst jetzt alle Commits, die diese Datei betreffen.
  4. Klicke auf einen Commit und dann doppelt auf database.php in der Dateiliste.
  5. Die Diff-Ansicht zeigt dir genau, welche Zeilen du damals geändert hast.

Zusammenfassung

Aktion Weg in PhpStorm
Gesamte Historie anzeigen Git → Show Git Log oder Alt + 9
Änderungen eines Commits sehen Commit anklicken → Datei doppelklicken
Historie einer Datei Rechtsklick → Git → Show History
Wer hat welche Zeile geschrieben? Rechtsklick im Editor → Annotate with Git Blame
Nach Commits suchen Suchfeld im Log-Fenster nutzen

Mit diesen Werkzeugen hast du deine Projektgeschichte immer im Griff – du kannst jederzeit nachvollziehen, was sich wann und warum geändert hat. 🎯

Kapitel 4: Commits erstellen und verstehen

Den letzten Commit in PhpStorm korrigieren 🔧

Es passiert jedem: Du hast gerade auf „Commit" geklickt und merkst sofort, dass du eine Datei vergessen hast oder sich ein peinlicher Tippfehler in die Commit-Nachricht eingeschlichen hat. Die gute Nachricht: Git bietet genau für diesen Fall eine elegante Lösung – das sogenannte Amend (englisch für „ändern" oder „verbessern"). Und PhpStorm macht es dir besonders einfach, diese Funktion zu nutzen.

Was bedeutet „Amend" eigentlich?

Wenn du einen Commit „amendest", ersetzt du den letzten Commit durch einen neuen. Dabei kannst du:

Wichtig zu verstehen: Der alte Commit wird nicht wirklich „bearbeitet", sondern durch einen komplett neuen Commit ersetzt. Für dich sieht es so aus, als hättest du den Fehler nie gemacht – die Historie bleibt sauber.

⚠️ Achtung: Du solltest Amend nur verwenden, wenn du den Commit noch nicht gepusht hast. Sobald ein Commit auf einem Remote-Repository (z. B. GitHub) liegt und andere damit arbeiten könnten, kann das Ändern der Historie zu Problemen führen. Für lokale, noch nicht geteilte Commits ist Amend aber völlig unbedenklich.

Schritt-für-Schritt-Anleitung in PhpStorm

Fall 1: Du hast eine Datei vergessen

  1. Nimm die gewünschten Änderungen vor
    Bearbeite die vergessene Datei oder füge sie dem Projekt hinzu – ganz normal, wie du es sonst auch tun würdest.

  2. Öffne das Commit-Fenster
    Drücke Ctrl + K (Windows/Linux) bzw. Cmd + K (macOS), oder gehe über Git → Commit…

  3. Wähle die nachzureichenden Dateien aus
    Im Commit-Fenster siehst du links die Liste der geänderten Dateien. Setze den Haken bei den Dateien, die du zum letzten Commit hinzufügen möchtest.

  4. Aktiviere die Amend-Option
    Im Commit-Fenster findest du ein kleines Zahnrad-Symbol ⚙️ oder direkt eine Checkbox mit der Beschriftung „Amend commit" (manchmal auch „Amend" genannt). Diese Option befindet sich typischerweise:

    • Rechts neben dem Eingabefeld für die Commit-Nachricht, oder
    • Im Dropdown-Menü des Commit-Buttons

    Sobald du „Amend" aktivierst, passiert etwas Praktisches: Die Commit-Nachricht des letzten Commits wird automatisch ins Textfeld geladen.

  5. Commit-Nachricht anpassen (optional)
    Wenn die Nachricht bereits passt, lass sie so. Wenn du sie ändern möchtest, kannst du das jetzt tun.

  6. Commit abschließen
    Klicke auf Commit (nicht auf „Commit and Push"!). Der letzte Commit wird nun durch den neuen, korrigierten Commit ersetzt.

Fall 2: Du möchtest nur die Commit-Nachricht ändern

Manchmal hast du keine Dateien vergessen, sondern nur einen Tippfehler in der Nachricht oder möchtest sie präziser formulieren. Das geht noch schneller:

  1. Öffne das Commit-Fenster (Ctrl + K / Cmd + K)

  2. Aktiviere „Amend commit"
    Die alte Nachricht erscheint im Textfeld.

  3. Korrigiere die Nachricht
    Schreibe die Nachricht so, wie sie sein sollte.

  4. Stelle sicher, dass keine Dateien ausgewählt sind
    Wenn du wirklich nur die Nachricht ändern willst, sollten keine neuen Dateien angehakt sein. PhpStorm wird dann nur die Nachricht aktualisieren.

  5. Klicke auf Commit

Visueller Überblick

flowchart TD
    A["Letzter Commit ist fehlerhaft\n- Datei vergessen?\n- Nachricht falsch?"] --> B["Aenderungen vornehmen\noder direkt Commit-Fenster oeffnen"]
    B --> C["Commit-Fenster oeffnen\nStrg+K / Cmd+K"]
    C --> D["Option 'Amend commit'\naktivieren"]
    D --> E{"Was korrigieren?"}
    E -->|Dateien nachreichen| F["Dateien auswaehlen\nund Commit"]
    E -->|Nur Nachricht| G["Nachricht korrigieren\nund Commit"]
    F --> H["Alter Commit wird ersetzt\nHistorie bleibt sauber"]
    G --> H

Wo finde ich die Amend-Option genau?

Je nach PhpStorm-Version kann die Oberfläche leicht variieren. Hier die typischen Stellen:

PhpStorm-Version Position der Amend-Option
Neuere Versionen (2021+) Direkt unter dem Nachrichtenfeld als Checkbox „Amend" oder im Zahnrad-Menü ⚙️ rechts
Ältere Versionen Im Dropdown-Pfeil neben dem „Commit"-Button → „Commit and Amend"

Wenn du die Option nicht sofort siehst, schau nach einem Zahnrad-Symbol oder einem kleinen Pfeil neben dem Commit-Button – dort verstecken sich oft erweiterte Optionen.

Was passiert technisch im Hintergrund?

Wenn du in der Kommandozeile arbeiten würdest, entspräche das Ganze diesem Befehl:

git commit --amend

Oder, wenn du auch Dateien hinzufügen möchtest:

git add vergessene_datei.php
git commit --amend

Git erstellt dabei einen neuen Commit mit einer neuen ID (dem sogenannten Hash), der den alten ersetzt. Der alte Commit existiert technisch noch kurz im Hintergrund, wird aber nicht mehr referenziert und irgendwann automatisch aufgeräumt.

Häufige Fragen und Stolperfallen

„Kann ich auch ältere Commits ändern, nicht nur den letzten?"

Ja, aber das ist deutlich komplizierter und erfordert einen sogenannten Interactive Rebase. Für den Anfang solltest du dich auf das Amenden des letzten Commits beschränken – das deckt 90 % der Fälle ab.

„Ich habe schon gepusht – was jetzt?"

Wenn du einen bereits gepushten Commit amendest und dann erneut pushen willst, wird Git sich beschweren, weil die Historien nicht mehr übereinstimmen. Du könntest einen Force Push machen (git push --force), aber das ist gefährlich, wenn andere mit dem Repository arbeiten. Bei persönlichen Projekten, an denen nur du arbeitest, ist es meist okay – aber sei vorsichtig.

„Was, wenn ich Amend aus Versehen aktiviert habe?"

Keine Panik! Solange du noch nicht auf „Commit" geklickt hast, kannst du die Checkbox einfach wieder deaktivieren. Falls du den Amend-Commit bereits gemacht hast, kannst du mit git reflog (im Terminal) den alten Commit wiederfinden – aber das ist ein fortgeschrittenes Thema.

Zusammenfassung ✅

Situation Lösung in PhpStorm
Datei im letzten Commit vergessen Datei auswählen → „Amend commit" aktivieren → Commit
Commit-Nachricht korrigieren „Amend commit" aktivieren → Nachricht ändern → Commit
Bereits gepushter Commit ⚠️ Amend vermeiden oder Force Push (nur bei Solo-Projekten)

Das Amenden ist eines der nützlichsten Features für den Alltag – es hält deine Commit-Historie sauber und erspart dir peinliche „Datei vergessen"-Commits. Nutze es ruhig großzügig, solange du noch nicht gepusht hast! 🎯

Kapitel 5: Mit Branches arbeiten

Einleitung: Branches (Verzweigungen) sind eines der mächtigsten Features von Git. Stell dir deinen Code wie einen Baum vor: Der Hauptstamm ist dein funktionierender Code, und jeder Branch ist ein Ast, auf dem du experimentieren kannst, ohne den Stamm zu gefährden. Wenn du ein neues Feature entwickelst oder einen Bug behebst, erstellst du einen separaten Branch, arbeitest dort in Ruhe, und führst die Änderungen erst zusammen (Merge), wenn alles funktioniert. So bleibt dein Hauptcode immer stabil. Allerdings kann es beim Zusammenführen zu Konflikten kommen, wenn dieselbe Stelle unterschiedlich bearbeitet wurde. Dieses Kapitel zeigt dir, wie du Branches sicher handhabst.

Kapitel 5: Mit Branches arbeiten

Branches in Git – parallele Entwicklungslinien verstehen 🌿

Stell dir vor, du arbeitest an deinem Webprojekt und alles läuft stabil. Plötzlich hast du eine Idee für ein neues Feature – aber du bist dir nicht sicher, ob es funktioniert. Oder ein Kunde meldet einen dringenden Bug, während du gerade mitten in einer größeren Umbauaktion steckst. Genau für solche Situationen gibt es Branches.

Was ist ein Branch?

Ein Branch (englisch für „Zweig") ist im Grunde eine eigenständige Entwicklungslinie in deinem Git-Repository. Du kannst dir das wie parallele Universen deines Projekts vorstellen: In jedem Branch existiert eine eigene Version deines Codes, und Änderungen in einem Branch beeinflussen die anderen nicht – bis du sie bewusst zusammenführst.

Wenn du ein neues Repository erstellst, startest du automatisch auf einem Branch namens main (früher oft master). Dieser Branch enthält üblicherweise die stabile, funktionierende Version deines Projekts. Von hier aus kannst du beliebig viele weitere Branches abzweigen.

gitGraph
   commit id: "Projekt Start"
   commit id: "Erste Seiten"
   branch feature/kontaktformular
   checkout feature/kontaktformular
   commit id: "Formular HTML"
   commit id: "Validierung"
   checkout main
   commit id: "Bugfix Header"
   merge feature/kontaktformular id: "Merge Feature"
   commit id: "Weiterentwicklung"

Warum sind Branches so nützlich?

Branches lösen mehrere Probleme gleichzeitig, die ohne sie schnell zum Chaos führen würden:

Wann sollte ich einen neuen Branch erstellen?

Als Faustregel gilt: Erstelle einen neuen Branch, wenn du etwas Neues ausprobierst oder eine abgeschlossene Einheit entwickelst. Hier sind typische Situationen:

  1. Neues Feature entwickeln

    Du möchtest ein Kontaktformular, einen Login-Bereich oder eine neue Seite hinzufügen. Erstelle einen Branch wie feature/kontaktformular oder feature/user-login.

  2. Bugfix durchführen

    Ein Fehler muss behoben werden, während du gerade an etwas anderem arbeitest. Erstelle einen Branch wie bugfix/header-navigation oder fix/mobile-layout.

  3. Experimentieren

    Du willst ein neues CSS-Framework testen oder eine Funktion komplett umbauen, bist dir aber nicht sicher, ob es klappt. Ein Branch wie experiment/tailwind-migration gibt dir die Freiheit, ohne Konsequenzen zu testen.

  4. Größere Refactorings

    Du willst deinen Code grundlegend umstrukturieren. Das dauert mehrere Commits und zwischendurch ist der Code möglicherweise kaputt. Ein eigener Branch wie refactor/datenbank-struktur hält deinen main-Branch sauber.

Praktisches Beispiel: Ein kleines Webprojekt

Nehmen wir an, du entwickelst eine einfache Portfolio-Website mit PHP. Dein main-Branch enthält bereits die Startseite und eine Über-mich-Seite, und alles funktioniert. Jetzt stehen drei Aufgaben an:

Ausgangssituation

main
 └── index.php (Startseite)
 └── about.php (Über mich)
 └── style.css (Styling)

Aufgabe 1: Kontaktformular entwickeln

Du erstellst einen neuen Branch:

git checkout -b feature/kontaktformular

Jetzt arbeitest du in diesem Branch an contact.php, fügst Formularvalidierung hinzu und passt das CSS an. Du machst mehrere Commits:

Währenddessen bleibt main unverändert und stabil.

Aufgabe 2: Dringender Bugfix

Ein Besucher meldet, dass die Navigation auf dem Handy nicht funktioniert. Du wechselst zurück zu main und erstellst von dort einen Bugfix-Branch:

git checkout main
git checkout -b bugfix/mobile-navigation

Du behebst den Fehler und committest:

Dieser Fix ist dringend, also mergst du ihn direkt zurück in main:

git checkout main
git merge bugfix/mobile-navigation

Dein main-Branch hat jetzt den Bugfix, aber das Kontaktformular ist noch nicht drin – es wartet noch in seinem eigenen Branch.

Aufgabe 3: Feature fertigstellen und mergen

Du wechselst zurück zu deinem Feature-Branch und arbeitest weiter:

git checkout feature/kontaktformular

Sobald das Kontaktformular fertig und getestet ist, führst du es mit main zusammen:

git checkout main
git merge feature/kontaktformular

Endergebnis

Dein main-Branch enthält jetzt sowohl den Bugfix als auch das neue Feature – sauber getrennt entwickelt und zusammengeführt.

gitGraph
   commit id: "Startseite"
   commit id: "Über-mich-Seite"
   branch feature/kontaktformular
   checkout feature/kontaktformular
   commit id: "Formular HTML"
   checkout main
   branch bugfix/mobile-navigation
   checkout bugfix/mobile-navigation
   commit id: "Navigation gefixt"
   checkout main
   merge bugfix/mobile-navigation id: "Bugfix live"
   checkout feature/kontaktformular
   commit id: "Validierung"
   commit id: "Erfolgsmeldung"
   checkout main
   merge feature/kontaktformular id: "Feature live"

Branch-Namenskonventionen

Um Ordnung zu halten, haben sich bestimmte Namens-Präfixe etabliert:

Präfix Verwendung Beispiel
feature/ Neue Funktionen feature/newsletter-anmeldung
bugfix/ oder fix/ Fehlerbehebungen bugfix/login-fehler
hotfix/ Dringende Fixes für Produktion hotfix/sicherheitsluecke
experiment/ Experimente ohne Garantie experiment/neues-framework
refactor/ Code-Umstrukturierungen refactor/datenbankzugriff

Diese Präfixe sind keine Git-Vorgabe, sondern eine bewährte Konvention. Sie helfen dir (und anderen), auf einen Blick zu erkennen, worum es in einem Branch geht.

Zusammenfassung

Branches sind eines der mächtigsten Konzepte in Git. Sie erlauben dir, gefahrlos zu experimentieren, parallel an mehreren Dingen zu arbeiten und deinen Hauptzweig stabil zu halten. Für ein kleines Webprojekt reicht oft ein einfaches Muster: Arbeite auf main, aber erstelle für jedes neue Feature oder jeden Bugfix einen eigenen Branch – und merge ihn erst, wenn er fertig ist. 🎯

Kapitel 5: Mit Branches arbeiten

Branches in PhpStorm erstellen und wechseln 🌿

Das Arbeiten mit Branches gehört zu den wichtigsten Git-Funktionen, und PhpStorm macht es dir besonders leicht, neue Branches zu erstellen und zwischen ihnen zu wechseln – ganz ohne Terminal.

Einen neuen Branch erstellen

Es gibt mehrere Wege, um in PhpStorm einen neuen Branch anzulegen:

Weg 1: Über die Branch-Anzeige in der Statusleiste

  1. Schau in die rechte untere Ecke von PhpStorm – dort siehst du den Namen deines aktuellen Branches (z. B. „main" oder „master").

  2. Klicke auf den Branch-Namen – es öffnet sich ein Popup-Menü mit allen verfügbaren Branches.

  3. Wähle New Branch (oder „Neuer Branch" in der deutschen Version).

  4. Gib einen aussagekräftigen Namen für deinen Branch ein, z. B.:

    • feature/kontaktformular
    • bugfix/login-fehler
    • experiment/neues-design

  5. Aktiviere die Option Checkout branch (standardmäßig aktiv), damit du direkt in den neuen Branch wechselst.

  6. Bestätige mit Create.

Weg 2: Über das Git-Menü

  1. Gehe zu Git → New Branch… in der Menüleiste.

  2. Der weitere Ablauf ist identisch: Name eingeben, Checkout-Option wählen, bestätigen.

Weg 3: Über das Git-Tool-Fenster

  1. Öffne das Git-Fenster am unteren Rand von PhpStorm (Reiter „Git").

  2. Wechsle zum Tab Log und klicke mit der rechten Maustaste auf einen beliebigen Commit.

  3. Wähle New Branch… – der neue Branch startet dann an genau diesem Commit.

💡 Tipp: Die dritte Variante ist besonders nützlich, wenn du einen Branch nicht vom aktuellen Stand, sondern von einem älteren Commit aus erstellen möchtest.

Zwischen Branches wechseln

Das Wechseln zwischen Branches nennt man in Git Checkout. In PhpStorm geht das schnell:

Über die Statusleiste (empfohlen)

  1. Klicke wieder auf den Branch-Namen in der rechten unteren Ecke.

  2. Du siehst eine Liste aller lokalen Branches (unter „Local") und – falls vorhanden – auch der Remote-Branches (unter „Remote").

  3. Klicke auf den gewünschten Branch und wähle Checkout.

  4. PhpStorm wechselt sofort in den ausgewählten Branch, und dein Arbeitsverzeichnis zeigt nun den Stand dieses Branches.

Über das Git-Menü

Alternativ kannst du Git → Branches… wählen – das öffnet dasselbe Popup wie der Klick auf die Statusleiste.

Was passiert beim Branch-Wechsel im Hintergrund?

Wenn du den Branch wechselst, passieren mehrere Dinge:

flowchart TD
    A["Du waehlst Branch 'feature/login'"] --> B["Git prueft auf ungespeicherte Aenderungen"]
    B -->|Keine Konflikte| C["HEAD zeigt jetzt auf 'feature/login'"]
    C --> D["Dateien im Arbeitsverzeichnis\nwerden angepasst"]
    D --> E["PhpStorm aktualisiert\nalle offenen Editoren"]
    B -->|Konflikte moeglich| F["PhpStorm fragt:\nStashen, Committen oder Abbrechen?"]

Wichtig zu verstehen:

Umgang mit ungespeicherten Änderungen

Was passiert, wenn du Änderungen hast, die noch nicht committet sind, und trotzdem den Branch wechseln willst?

PhpStorm zeigt dir in diesem Fall einen Dialog mit mehreren Optionen:

Option Bedeutung
Smart Checkout PhpStorm versucht, deine Änderungen in den neuen Branch „mitzunehmen". Funktioniert oft, aber nicht immer konfliktfrei.
Force Checkout Deine lokalen Änderungen werden verworfen – Vorsicht, Datenverlust möglich!
Don't Checkout Der Wechsel wird abgebrochen, du bleibst im aktuellen Branch.
Stash & Checkout Deine Änderungen werden temporär „versteckt" (gestasht), der Branch wird gewechselt, und du kannst den Stash später wieder anwenden.

💡 Empfehlung für Anfänger: Am sichersten ist es, vor einem Branch-Wechsel entweder zu committen oder die Änderungen mit Stash zwischenzuspeichern. So gehst du kein Risiko ein.

Praktisches Beispiel: Feature-Entwicklung

Angenommen, du arbeitest an einem Blog-Projekt und möchtest ein Kontaktformular hinzufügen, ohne deinen stabilen Code zu gefährden:

  1. Branch erstellen:
    Klicke auf „main" → New Branch → Name: feature/kontaktformular → Create

  2. Entwickeln:
    Du bist jetzt im neuen Branch und kannst arbeiten. Alle Commits landen nur in diesem Branch.

  3. Zwischendurch zum Hauptbranch wechseln:
    Ein dringender Bug wird gemeldet. Klicke auf „feature/kontaktformular" → wähle „main" → Checkout. Du bist zurück im stabilen Code.

  4. Bug fixen, committen, zurückwechseln:
    Nach dem Fix wechselst du wieder zu „feature/kontaktformular" und arbeitest weiter am Formular.

Branches löschen

Wenn ein Branch nicht mehr gebraucht wird (z. B. nach einem Merge), kannst du ihn löschen:

  1. Klicke auf den Branch-Namen in der Statusleiste.
  2. Finde den zu löschenden Branch in der Liste.
  3. Klicke mit der rechten Maustaste darauf (oder hover und klicke auf das Drei-Punkte-Menü).
  4. Wähle Delete.

⚠️ Hinweis: Den Branch, in dem du dich gerade befindest, kannst du nicht löschen. Wechsle vorher in einen anderen Branch.

Zusammenfassung der wichtigsten Aktionen

Aktion Weg in PhpStorm
Neuen Branch erstellen Statusleiste → Branch-Name → New Branch
Branch wechseln Statusleiste → Branch-Name → gewünschten Branch → Checkout
Aktuellen Branch sehen Rechte untere Ecke der Statusleiste
Branch löschen Statusleiste → Rechtsklick auf Branch → Delete
Alle Branches anzeigen Git-Fenster → Tab Log → linke Spalte „Branches"

Mit diesen Grundlagen kannst du effektiv mit Branches arbeiten und verschiedene Features oder Experimente sauber voneinander trennen – ohne Angst haben zu müssen, deinen funktionierenden Code zu zerstören. 🎯

Kapitel 5: Mit Branches arbeiten

Feature-Branch in den Main-Branch mergen – Schritt für Schritt in PhpStorm 🔀

Du hast in deinem Feature-Branch (z. B. login-formular) alle Änderungen abgeschlossen und getestet. Jetzt ist es Zeit, diese Arbeit in deinen Hauptbranch (meist main oder master) zu integrieren. Diesen Vorgang nennt man Merge – und PhpStorm macht ihn dir besonders komfortabel.

Das Grundprinzip verstehen

Beim Mergen passiert Folgendes: Git nimmt alle Änderungen aus deinem Feature-Branch und fügt sie in einen anderen Branch ein (den Zielbranch). Wichtig dabei ist die Reihenfolge:

flowchart LR
    A["1. Wechsle zum Zielbranch\n(z.B. main)"] --> B["2. Merge den Feature-Branch\nin den aktuellen Branch"]
    B --> C["3. Aenderungen sind\njetzt in main"]

💡 Merke: Du wechselst immer zuerst in den Branch, der die Änderungen empfangen soll, und holst dann den anderen Branch hinein.

Schritt-für-Schritt-Anleitung

1. Offene Änderungen committen

Bevor du mergst, stelle sicher, dass in beiden Branches keine uncommitteten Änderungen herumliegen. Öffne das Commit-Fenster (Ctrl + K / Cmd + K) und prüfe, ob alles sauber committet ist. Falls du noch Änderungen im Feature-Branch hast, committe diese zuerst.

2. Zum Main-Branch wechseln

Da du die Änderungen in den Main-Branch integrieren willst, musst du dorthin wechseln:

  1. Schau in die rechte untere Ecke von PhpStorm – dort siehst du den aktuellen Branch-Namen.
  2. Klicke darauf – es öffnet sich das Branch-Popup.
  3. Suche deinen Main-Branch (z. B. main oder master) unter Local Branches.
  4. Klicke auf den Branch-Namen und wähle Checkout.

PhpStorm wechselt nun zum Main-Branch. Du siehst, dass sich der Name in der Statusleiste ändert, und dein Working Directory zeigt jetzt den Stand des Main-Branches.

3. Den Feature-Branch mergen

Jetzt kommt der eigentliche Merge:

  1. Klicke erneut auf den Branch-Namen in der Statusleiste (jetzt steht dort „main").
  2. Im Popup siehst du unter Local Branches deinen Feature-Branch (z. B. login-formular).
  3. Klicke auf den Feature-Branch und wähle im Untermenü Merge into Current.

PhpStorm führt nun den Merge durch. Wenn alles glatt läuft (keine Konflikte), siehst du eine kurze Erfolgsmeldung, und die Änderungen aus deinem Feature-Branch sind jetzt Teil des Main-Branches.

4. Das Ergebnis überprüfen

Nach dem Merge lohnt sich ein kurzer Blick ins Git-Log (Alt + 9 oder Git → Show Git Log):

Was passiert im Hintergrund?

Wenn du in PhpStorm „Merge into Current" auswählst, führt Git im Hintergrund folgenden Befehl aus:

git merge login-formular

Dabei erstellt Git (je nach Situation) entweder:

Was tun bei Merge-Konflikten? ⚠️

Manchmal hat Git ein Problem: Wenn dieselbe Stelle in einer Datei in beiden Branches unterschiedlich geändert wurde, kann Git nicht automatisch entscheiden, welche Version gelten soll. Das nennt man einen Merge-Konflikt.

In diesem Fall öffnet PhpStorm automatisch ein Konfliktlösungs-Fenster:

  1. Du siehst drei Spalten: Links dein aktueller Branch (Main), rechts der Feature-Branch, in der Mitte das Ergebnis.
  2. Für jede Konfliktstelle kannst du entscheiden:
    • Accept Left – die Version aus Main übernehmen
    • Accept Right – die Version aus dem Feature-Branch übernehmen
    • Manuell bearbeiten – in der Mitte selbst eine Kombination schreiben
  3. Wenn alle Konflikte gelöst sind, klicke auf Apply.
  4. PhpStorm erstellt dann automatisch den Merge-Commit.

🛠️ Tipp: Konflikte klingen schlimmer als sie sind. In den meisten Fällen ist schnell klar, welche Version die richtige ist – und das visuelle Tool von PhpStorm macht die Lösung sehr intuitiv.

Nach dem Merge: Feature-Branch löschen?

Wenn der Merge erfolgreich war und du den Feature-Branch nicht mehr brauchst, kannst du ihn aufräumen:

  1. Klicke wieder auf den Branch-Namen in der Statusleiste.
  2. Finde deinen Feature-Branch unter Local Branches.
  3. Klicke darauf und wähle Delete.

Das hält deine Branch-Liste übersichtlich. Die Commits gehen dabei nicht verloren – sie sind jetzt Teil des Main-Branches und bleiben in der Historie erhalten.

Zusammenfassung

Schritt Aktion in PhpStorm
1. Alles committen Ctrl/Cmd + K → Commit
2. Zum Zielbranch wechseln Branch-Popup → Main → Checkout
3. Feature-Branch mergen Branch-Popup → Feature-Branch → Merge into Current
4. Bei Konflikten Konflikt-Dialog nutzen → Apply
5. Optional aufräumen Branch-Popup → Feature-Branch → Delete

Mit dieser Routine kannst du sicher neue Features entwickeln, testen und dann sauber in deinen Hauptbranch integrieren – genau so, wie es in professionellen Projekten üblich ist. 🎉

Kapitel 5: Mit Branches arbeiten

Merge-Konflikte verstehen und in PhpStorm lösen 🔧

Ein Merge-Konflikt ist einer der Momente, vor denen Git-Anfänger oft Respekt haben – aber wenn du einmal verstanden hast, was passiert und wie du damit umgehst, verliert er schnell seinen Schrecken. PhpStorm bietet dir dafür ein hervorragendes visuelles Werkzeug, das die Auflösung deutlich erleichtert.

Was ist ein Merge-Konflikt?

Ein Merge-Konflikt entsteht, wenn Git nicht automatisch entscheiden kann, wie zwei unterschiedliche Änderungen zusammengeführt werden sollen. Das passiert, wenn dieselbe Stelle in einer Datei in beiden Branches verändert wurde – Git weiß dann nicht, welche Version die „richtige" ist und bittet dich um Hilfe.

Wann tritt ein Konflikt auf?

Konflikte entstehen typischerweise in diesen Situationen:

Wann gibt es keinen Konflikt?

Wenn die Änderungen in unterschiedlichen Dateien oder in unterschiedlichen Bereichen derselben Datei stattfinden, kann Git diese problemlos automatisch zusammenführen – kein Konflikt.

Ein konkretes Beispiel

Stell dir vor, du hast eine Datei config.php mit folgender Zeile:

$siteTitle = "Meine Website";

Jetzt passiert Folgendes:

  1. Im Main-Branch änderst du die Zeile zu:

    $siteTitle = "Meine tolle Website";

  2. Im Feature-Branch (den du vorher vom Main-Branch abgezweigt hast) änderst du dieselbe Zeile zu:

    $siteTitle = "Mein Webprojekt";

Wenn du jetzt versuchst, den Feature-Branch in den Main-Branch zu mergen, hat Git ein Problem: Beide Branches haben dieselbe Zeile unterschiedlich verändert. Git kann nicht wissen, ob du „Meine tolle Website" oder „Mein Webprojekt" haben möchtest – oder vielleicht sogar etwas ganz anderes.

flowchart TD
    A["Ursprung<br>$siteTitle = Meine Website"] --> B["Main-Branch<br>$siteTitle = Meine tolle Website"]
    A --> C["Feature-Branch<br>$siteTitle = Mein Webprojekt"]
    B --> D["Merge-Versuch"]
    C --> D
    D --> E["Konflikt!<br>Git weiss nicht,<br>welche Version gilt"]

Merge-Konflikt in PhpStorm lösen – Schritt für Schritt

Angenommen, du bist im Main-Branch und willst deinen Feature-Branch mergen:

  1. Merge starten

    Klicke unten rechts auf den Branch-Namen (z. B. „main"), wähle deinen Feature-Branch aus der Liste und klicke auf Merge into Current. Alternativ: Git → Merge… im Menü.

  2. Konflikt-Meldung erscheint

    Wenn ein Konflikt existiert, zeigt PhpStorm dir ein Dialogfenster mit dem Titel Merge Conflicts. Hier siehst du eine Liste aller Dateien, die Konflikte haben – in unserem Beispiel config.php.

  3. Konflikt-Editor öffnen

    Wähle die konfliktbehaftete Datei aus und klicke auf Merge… (oder doppelklicke auf die Datei). Es öffnet sich der 3-Wege-Merge-Editor – das Herzstück der Konfliktlösung in PhpStorm.

  4. Den 3-Wege-Editor verstehen

    Du siehst drei Spalten:

    Linke Spalte Mittlere Spalte Rechte Spalte
    Dein aktueller Branch (Main) Das Ergebnis (was am Ende gespeichert wird) Der eingehende Branch (Feature)

    Die konfliktbehafteten Stellen sind farblich hervorgehoben. In unserem Beispiel siehst du links „Meine tolle Website" und rechts „Mein Webprojekt".

  5. Änderungen übernehmen oder kombinieren

    Für jede konfliktbehaftete Stelle hast du mehrere Möglichkeiten:

    • Accept Left (Pfeil-Button neben der linken Version): Übernimmt die Version aus dem Main-Branch.

    • Accept Right (Pfeil-Button neben der rechten Version): Übernimmt die Version aus dem Feature-Branch.

    • Accept Both: Übernimmt beide Versionen nacheinander (selten sinnvoll bei derselben Zeile, aber nützlich bei Codeblöcken).

    • Manuell bearbeiten: Du kannst in der mittleren Spalte direkt den Text anpassen und etwas völlig Neues schreiben, z. B.:

      $siteTitle = "Mein tolles Webprojekt";

  6. Alle Konflikte lösen

    Gehe jeden markierten Konflikt durch und triff eine Entscheidung. Die mittlere Spalte zeigt dir immer das aktuelle Ergebnis. Sobald alle Konflikte gelöst sind (keine roten Markierungen mehr), wird der Apply-Button aktiv.

  7. Änderungen übernehmen

    Klicke auf Apply. Der Konflikt für diese Datei ist gelöst. Wenn es mehrere Dateien mit Konflikten gibt, wiederhole den Prozess für jede.

  8. Merge abschließen

    Nachdem alle Konflikte gelöst sind, erstellt PhpStorm automatisch einen Merge-Commit. Du kannst die vorgeschlagene Commit-Nachricht anpassen (z. B. „Merge branch ‚feature-xyz' into main") und den Commit bestätigen.

Tipps für den Umgang mit Konflikten

Zusammenfassung

Ein Merge-Konflikt entsteht, wenn Git zwei unterschiedliche Änderungen an derselben Stelle nicht automatisch zusammenführen kann. Das ist kein Fehler, sondern eine Aufforderung zur Entscheidung. PhpStorm bietet dir mit dem 3-Wege-Merge-Editor ein mächtiges Werkzeug, um diese Konflikte visuell und komfortabel zu lösen – du siehst beide Versionen nebeneinander, kannst gezielt auswählen oder kombinieren und behältst immer die volle Kontrolle über das Ergebnis.

Kapitel 6: GitHub einrichten und verbinden

Einleitung: Bisher hast du nur lokal gearbeitet – dein Code existiert ausschließlich auf deinem Computer. Das ist riskant: Ein Festplattendefekt, und alles ist weg. GitHub löst dieses Problem, indem es dein Repository in der Cloud speichert. Aber GitHub ist mehr als nur ein Backup: Es ist eine Plattform, die Zusammenarbeit ermöglicht, dein Portfolio als Entwickler präsentiert und viele nützliche Werkzeuge bietet. Um sicher mit GitHub zu kommunizieren, wirst du SSH-Keys einrichten – eine Art digitaler Schlüssel, der deinen Computer bei GitHub identifiziert. Dieses Kapitel führt dich durch die Kontoerstellung, die Sicherheitseinrichtung und die Verknüpfung deines ersten Projekts.

Kapitel 6: GitHub einrichten und verbinden

Einen GitHub-Account erstellen – Schritt für Schritt 🐙

Du möchtest deinen Code online sichern, von überall darauf zugreifen oder später vielleicht sogar mit anderen zusammenarbeiten? Dann ist ein GitHub-Account der logische nächste Schritt nach der lokalen Git-Einrichtung. GitHub ist die weltweit größte Plattform für Code-Hosting und Versionsverwaltung – und die Registrierung ist kostenlos. Hier erfährst du, wie du deinen Account erstellst und welche Einstellungen du von Anfang an im Blick haben solltest.

Die Registrierung durchführen

  1. GitHub-Website aufrufen

    Öffne deinen Browser und gehe zu github.com. Auf der Startseite siehst du prominent einen Button wie „Sign up" oder „Registrieren".

  2. E-Mail-Adresse eingeben

    GitHub fragt dich zuerst nach deiner E-Mail-Adresse. Verwende eine Adresse, auf die du langfristig Zugriff hast – idealerweise dieselbe, die du auch in deiner lokalen Git-Konfiguration eingetragen hast. Das sorgt dafür, dass deine Commits später korrekt mit deinem GitHub-Profil verknüpft werden.

  3. Passwort wählen

    Wähle ein starkes, einzigartiges Passwort. GitHub enthält oft sensiblen Code und ist ein attraktives Ziel für Angreifer. Ein Passwort-Manager kann hier sehr hilfreich sein.

  4. Benutzernamen festlegen

    Der Benutzername ist ein wichtiger Punkt, über den du dir vorab Gedanken machen solltest (siehe nächster Abschnitt).

  5. E-Mail-Verifizierung

    GitHub schickt dir eine Bestätigungs-E-Mail. Klicke auf den Link darin, um deine Adresse zu verifizieren – erst dann ist dein Account vollständig aktiviert.

  6. Optionale Personalisierung

    Nach der Registrierung führt dich GitHub durch ein paar optionale Fragen (z. B. „Wofür nutzt du GitHub?" oder „Wie groß ist dein Team?"). Diese dienen hauptsächlich dazu, dir passende Empfehlungen zu geben – du kannst sie überspringen, wenn du möchtest.

Den richtigen Benutzernamen wählen

Der Benutzername auf GitHub ist öffentlich sichtbar und Teil der URL zu deinen Repositories (z. B. github.com/deinname/projekt). Deshalb lohnt es sich, hier einen Moment nachzudenken:

💡 Tipp: Wenn du planst, GitHub als Portfolio zu nutzen, überlege, ob der Name zu deinem „Personal Branding" passt – also zu dem Eindruck, den du hinterlassen möchtest.

Wichtige Profileinstellungen nach der Registrierung

Sobald dein Account steht, solltest du einen Blick in die Einstellungen werfen. Du erreichst sie über dein Profilbild oben rechts → Settings. Hier die wichtigsten Bereiche:

Profil-Informationen

Unter Public profile kannst du grundlegende Informationen über dich hinterlegen:

Diese Informationen sind öffentlich und helfen anderen, dich einzuordnen – besonders wenn du in Open-Source-Projekten aktiv wirst oder dein Profil als Portfolio nutzt.

E-Mail-Einstellungen

Unter Emails findest du wichtige Optionen:

⚠️ Wichtig: Wenn du deine lokale Git-Konfiguration mit einer privaten E-Mail-Adresse eingerichtet hast und diese nicht öffentlich sein soll, aktiviere unbedingt die Datenschutzoptionen und verwende die von GitHub bereitgestellte No-Reply-Adresse.

Zwei-Faktor-Authentifizierung einrichten

Unter Password and authentication findest du die Option zur Two-factor authentication (2FA). Diese solltest du dringend aktivieren:

Die Einrichtung dauert nur wenige Minuten und erhöht die Sicherheit deines Accounts erheblich.

SSH-Keys und Personal Access Tokens

Für die Verbindung zwischen deinem lokalen Rechner und GitHub gibt es zwei gängige Methoden:

Für den Anfang kannst du diesen Schritt überspringen – PhpStorm fragt dich beim ersten Push nach deinen Zugangsdaten und hilft dir bei der Einrichtung. Aber es ist gut zu wissen, wo du diese Optionen findest.

Repository-Sichtbarkeit verstehen

Wenn du später ein Repository auf GitHub erstellst, wirst du nach der Sichtbarkeit gefragt. Es gibt zwei Optionen:

Sichtbarkeit Bedeutung
Public Jeder kann das Repository sehen, auch ohne GitHub-Account. Der Code ist vollständig öffentlich. Andere können ihn ansehen, forken und bei Erlaubnis auch beitragen.
Private Nur du und Personen, denen du explizit Zugriff gibst, können das Repository sehen. Ideal für persönliche Projekte, Kundenprojekte oder Code, den du nicht teilen möchtest.

Für deine persönlichen Lern- und Übungsprojekte ist „Private" oft eine gute Wahl – du kannst sie jederzeit später öffentlich machen, wenn du sie zeigen möchtest. Für Open-Source-Projekte oder Portfolio-Stücke wählst du „Public".

💡 Gut zu wissen: Mit einem kostenlosen GitHub-Account kannst du unbegrenzt viele private Repositories erstellen – früher war das ein kostenpflichtiges Feature.

Die GitHub-Oberfläche im Überblick

Nach der Anmeldung landest du auf deinem Dashboard. Hier ein kurzer Überblick über die wichtigsten Bereiche:

flowchart TB
    A["GitHub Dashboard"] --> B["Repositories\nDeine Projekte"]
    A --> C["Explore\nOpen-Source entdecken"]
    A --> D["Notifications\nBenachrichtigungen"]
    A --> E["Settings\nAccount-Einstellungen"]
    B --> F["Neues Repository erstellen"]
    B --> G["Bestehende Repos verwalten"]

Zusammenfassung: Deine Checkliste nach der Registrierung ✅

Nachdem du deinen GitHub-Account erstellt hast, solltest du folgende Punkte abhaken:

  1. E-Mail verifiziert – damit alle Funktionen freigeschaltet sind
  2. Benutzername überprüft – ist er professionell und langfristig passend?
  3. Profil ausgefüllt – zumindest Name und eine kurze Bio
  4. E-Mail-Privatsphäre aktiviert – wenn du deine echte Adresse schützen möchtest
  5. Zwei-Faktor-Authentifizierung eingerichtet – für die Sicherheit deines Accounts
  6. Lokale Git-Konfiguration angepasst – falls du die No-Reply-Adresse von GitHub nutzen möchtest

Mit diesen Grundlagen bist du bestens gerüstet, um im nächsten Schritt dein erstes Repository auf GitHub zu erstellen und es mit deinem lokalen Projekt zu verbinden! 🚀

Kapitel 6: GitHub einrichten und verbinden

SSH-Keys für GitHub – Sichere Authentifizierung einrichten 🔐

Wenn du regelmäßig mit GitHub arbeitest, wirst du schnell merken, dass die Eingabe von Benutzername und Passwort bei jedem push oder pull lästig wird. Außerdem hat GitHub die Passwort-Authentifizierung über HTTPS für Git-Operationen inzwischen eingeschränkt. Die elegante und sichere Lösung heißt SSH-Key-Authentifizierung. In diesem Kapitel erfährst du, was SSH-Keys sind, warum sie für GitHub so wichtig sind und wie du sie Schritt für Schritt einrichtest.

Was sind SSH-Keys überhaupt?

SSH steht für Secure Shell und ist ein Protokoll für verschlüsselte Verbindungen zwischen Computern. Ein SSH-Key ist ein kryptografisches Schlüsselpaar, das aus zwei Teilen besteht:

Das Geniale an diesem System: Wenn du dich mit GitHub verbindest, beweist dein Computer durch den privaten Schlüssel, dass er zu dem öffentlichen Schlüssel gehört, der bei GitHub hinterlegt ist – ohne dass ein Passwort übertragen wird. Selbst wenn jemand die Verbindung abhören würde, könnte er sich nicht als du ausgeben.

flowchart LR
    A["🔑 Privater Schluessel\nBleibt auf deinem PC"] --- B["🔐 Kryptografisches\nSchluesselpaar"]
    B --- C["🌐 Oeffentlicher Schluessel\nWird bei GitHub hinterlegt"]
    
    D["💻 Dein Computer"] -->|Authentifizierung\nohne Passwort| E["☁️ GitHub Server"]

Warum brauche ich SSH-Keys für GitHub?

Es gibt mehrere gute Gründe, warum du SSH-Keys einrichten solltest:

  1. Sicherheit

    SSH-Keys sind deutlich sicherer als Passwörter. Ein typischer SSH-Key hat eine Länge von 256 bis 4096 Bit – das ist praktisch unknackbar. Selbst wenn jemand deinen Netzwerkverkehr mitliest, kann er deinen privaten Schlüssel nicht rekonstruieren.

  2. Komfort im Alltag

    Nach der einmaligen Einrichtung musst du bei git push oder git pull keine Zugangsdaten mehr eingeben. Der SSH-Agent auf deinem Computer übernimmt die Authentifizierung automatisch im Hintergrund.

  3. GitHub hat HTTPS-Passwörter eingeschränkt

    Seit August 2021 akzeptiert GitHub keine einfachen Passwörter mehr für Git-Operationen über HTTPS. Stattdessen müsstest du einen Personal Access Token verwenden – der ist allerdings lang, unpraktisch und muss regelmäßig erneuert werden. SSH-Keys sind die elegantere Alternative.

  4. Mehrere Geräte, eine Identität

    Du kannst auf jedem deiner Computer einen eigenen SSH-Key erstellen und bei GitHub hinterlegen. So behältst du die Kontrolle darüber, welche Geräte Zugriff auf deine Repositories haben, und kannst einzelne Keys jederzeit widerrufen.

SSH-Key erstellen – Schritt für Schritt

Die Einrichtung unterscheidet sich je nach Betriebssystem nur minimal. Ich zeige dir den Prozess für Windows, macOS und Linux – die Befehle sind weitgehend identisch.

Voraussetzungen prüfen

Bevor du loslegst, stelle sicher, dass du ein Terminal öffnen kannst:

Schritt 1: Prüfen, ob bereits ein SSH-Key existiert

Es ist möglich, dass du schon einen SSH-Key hast, ohne es zu wissen. Prüfe das mit folgendem Befehl:

ls -la ~/.ssh

Wenn du Dateien wie id_rsa, id_ed25519 oder ähnliche siehst (jeweils mit und ohne .pub-Endung), hast du bereits ein Schlüsselpaar. Du kannst dieses verwenden oder ein neues erstellen.

💡 Tipp: Wenn der Ordner ~/.ssh nicht existiert, ist das kein Problem – er wird beim Erstellen eines Keys automatisch angelegt.

Schritt 2: Neuen SSH-Key generieren

GitHub empfiehlt den modernen Ed25519-Algorithmus, der sicherer und schneller ist als das ältere RSA. Führe folgenden Befehl aus und ersetze die E-Mail-Adresse durch deine GitHub-E-Mail:

ssh-keygen -t ed25519 -C "deine-email@beispiel.de"

Was passiert jetzt?

  1. Speicherort wählen

    Du wirst gefragt, wo der Key gespeichert werden soll:

    Enter file in which to save the key (/home/deinname/.ssh/id_ed25519):

    Drücke einfach Enter, um den Standardpfad zu akzeptieren. Das ist in den allermeisten Fällen die richtige Wahl.

  2. Passphrase festlegen

    Anschließend wirst du nach einer Passphrase gefragt:

    Enter passphrase (empty for no passphrase):

    Hier hast du zwei Optionen:

    • Mit Passphrase (empfohlen): Gib ein sicheres Passwort ein. Falls jemand Zugriff auf deinen Computer bekommt, ist der Key trotzdem geschützt.
    • Ohne Passphrase: Drücke einfach Enter. Der Key funktioniert dann ohne zusätzliche Eingabe, ist aber weniger sicher.

    🔒 Empfehlung: Nutze eine Passphrase! Mit dem SSH-Agent (siehe weiter unten) musst du sie trotzdem nur einmal pro Sitzung eingeben.

  3. Bestätigung

    Nach erfolgreicher Erstellung siehst du eine Ausgabe wie diese:

    Your identification has been saved in /home/deinname/.ssh/id_ed25519
Your public key has been saved in /home/deinname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890 deine-email@beispiel.de

Du hast jetzt zwei neue Dateien:

Schritt 3: SSH-Agent starten und Key hinzufügen

Der SSH-Agent ist ein Hintergrundprogramm, das deine SSH-Keys verwaltet und bei Bedarf automatisch verwendet. So musst du die Passphrase nicht bei jeder Git-Operation eingeben.

Auf macOS und Linux:

eval "$(ssh-agent -s)"

Du siehst eine Ausgabe wie Agent pid 12345 – der Agent läuft jetzt.

Auf Windows (Git Bash):

eval "$(ssh-agent -s)"

Der Befehl ist identisch. In PowerShell kann es etwas anders sein – Git Bash ist hier die einfachere Wahl.

Key zum Agent hinzufügen:

ssh-add ~/.ssh/id_ed25519

Falls du eine Passphrase gesetzt hast, wirst du jetzt danach gefragt. Nach der Eingabe ist der Key geladen und du musst die Passphrase erst wieder eingeben, wenn du deinen Computer neu startest oder dich ab- und anmeldest.

Öffentlichen Schlüssel bei GitHub hinterlegen

Jetzt kommt der entscheidende Schritt: Du musst GitHub deinen öffentlichen Schlüssel mitteilen, damit GitHub weiß, dass Verbindungen mit deinem privaten Schlüssel vertrauenswürdig sind.

Schritt 1: Öffentlichen Schlüssel kopieren

Zeige den Inhalt deines öffentlichen Schlüssels an:

cat ~/.ssh/id_ed25519.pub

Du siehst eine lange Zeile, die ungefähr so aussieht:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG... (viele Zeichen) ...deine-email@beispiel.de

Kopiere diese gesamte Zeile in die Zwischenablage – inklusive ssh-ed25519 am Anfang und der E-Mail am Ende.

💡 Tipp für macOS: Du kannst den Key direkt in die Zwischenablage kopieren mit:

pbcopy < ~/.ssh/id_ed25519.pub

Auf Windows (Git Bash):

clip < ~/.ssh/id_ed25519.pub

Schritt 2: Key in GitHub einfügen

  1. Öffne github.com und melde dich an.

  2. Klicke auf dein Profilbild oben rechts und wähle Settings.

  3. In der linken Seitenleiste findest du den Bereich Access – klicke dort auf SSH and GPG keys.

  4. Klicke auf den grünen Button New SSH key.

  5. Fülle die Felder aus:

    • Title: Gib einen beschreibenden Namen ein, z. B. „MacBook Pro Arbeit" oder „Windows Desktop". So weißt du später, welcher Key zu welchem Gerät gehört.
    • Key type: Lass die Auswahl auf Authentication Key (Standard).
    • Key: Füge hier den kopierten öffentlichen Schlüssel ein.

  6. Klicke auf Add SSH key.

  7. GitHub fragt dich möglicherweise nach deinem Passwort zur Bestätigung – gib es ein.

Dein SSH-Key ist jetzt bei GitHub registriert! 🎉

Verbindung testen

Bevor du loslegst, solltest du prüfen, ob alles funktioniert:

ssh -T git@github.com

Beim ersten Mal wirst du gefragt, ob du dem Server vertraust:

The authenticity of host 'github.com (IP-Adresse)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Gib yes ein und drücke Enter. Wenn alles klappt, siehst du:

Hi dein-username! You've successfully authenticated, but GitHub does not provide shell access.

Diese Meldung bedeutet: Es funktioniert! Du bist authentifiziert, aber GitHub erlaubt keinen direkten Shell-Zugriff – das ist normal und beabsichtigt.

Repositories mit SSH verwenden

Jetzt, wo SSH eingerichtet ist, musst du darauf achten, die SSH-URL statt der HTTPS-URL zu verwenden, wenn du Repositories klonst oder verbindest.

Beim Klonen eines Repositories

Wenn du auf GitHub ein Repository öffnest und auf den grünen Code-Button klickst, siehst du mehrere Optionen. Wähle SSH und kopiere die URL, die so aussieht:

git@github.com:dein-username/dein-repository.git

Dann klonst du mit:

git clone git@github.com:dein-username/dein-repository.git

Ein bestehendes Repository auf SSH umstellen

Falls du ein Repository bereits mit HTTPS geklont hast, kannst du die Remote-URL ändern:

git remote set-url origin git@github.com:dein-username/dein-repository.git

Prüfe die Änderung mit:

git remote -v

Du solltest jetzt SSH-URLs sehen:

origin  git@github.com:dein-username/dein-repository.git (fetch)
origin  git@github.com:dein-username/dein-repository.git (push)

SSH in PhpStorm konfigurieren

PhpStorm verwendet normalerweise automatisch die SSH-Konfiguration deines Systems. Trotzdem lohnt es sich, die Einstellungen zu prüfen:

  1. Öffne File → Settings (auf macOS: PhpStorm → Settings).

  2. Navigiere zu Version Control → Git.

  3. Stelle sicher, dass SSH executable auf Native oder Built-in steht. Die Option Native nutzt die SSH-Installation deines Systems inklusive des SSH-Agents – das ist meist die beste Wahl.

  4. Unter Version Control → GitHub kannst du deinen GitHub-Account hinzufügen. Wähle hier Log In via GitHub oder, falls du Token bevorzugst, die entsprechende Option. Für Git-Operationen über SSH ist dieser Schritt optional, aber für einige PhpStorm-Features wie das Erstellen von Pull Requests nützlich.

Wenn du jetzt in PhpStorm ein Repository mit SSH-URL klonst oder pushst, sollte alles reibungslos funktionieren – ohne Passworteingabe.

Häufige Probleme und Lösungen

„Permission denied (publickey)"

Diese Fehlermeldung bedeutet, dass GitHub deinen SSH-Key nicht erkennt. Mögliche Ursachen:

SSH-Agent startet nicht automatisch

Auf Windows kann es sein, dass der SSH-Agent-Dienst nicht läuft. Öffne PowerShell als Administrator und führe aus:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Auf macOS kannst du den Key dauerhaft im Agent speichern, indem du diese Zeilen zu ~/.ssh/config hinzufügst (erstelle die Datei, falls sie nicht existiert):

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Mehrere GitHub-Accounts

Falls du mehrere GitHub-Accounts hast (z. B. privat und beruflich), kannst du für jeden einen eigenen Key erstellen und in ~/.ssh/config konfigurieren:

# Privater Account
Host github.com-privat
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_privat

# Beruflicher Account
Host github.com-arbeit
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_arbeit

Beim Klonen verwendest du dann den jeweiligen Host:

git clone git@github.com-privat:username/repo.git
git clone git@github.com-arbeit:firmenname/repo.git

Zusammenfassung

SSH-Keys sind die sichere und komfortable Methode, um dich bei GitHub zu authentifizieren. Nach der einmaligen Einrichtung sparst du dir die ständige Eingabe von Zugangsdaten und profitierst von einer deutlich höheren Sicherheit. Hier nochmal die wichtigsten Schritte im Überblick:

flowchart TD
    A["1. SSH-Key generieren\nssh-keygen -t ed25519 -C ..."] --> B["2. SSH-Agent starten\nund Key hinzufuegen"]
    B --> C["3. Oeffentlichen Key kopieren\ncat ~/.ssh/id_ed25519.pub"]
    C --> D["4. Key bei GitHub einfuegen\nSettings - SSH Keys"]
    D --> E["5. Verbindung testen\nssh -T git@github.com"]
    E --> F["6. SSH-URLs verwenden\ngit@github.com:user/repo.git"]

Mit dieser Einrichtung bist du bestens vorbereitet, um deine Repositories sicher und effizient mit GitHub zu synchronisieren – sei es über die Kommandozeile oder direkt aus PhpStorm heraus. 🚀

Kapitel 6: GitHub einrichten und verbinden

Lokales Git-Repository mit GitHub verbinden 🔗

Du hast also schon fleißig lokal commitet und möchtest jetzt deinen Code sicher in der Cloud haben – sei es als Backup, um von mehreren Geräten darauf zuzugreifen oder um später mit anderen zusammenzuarbeiten. Die Verbindung zwischen deinem lokalen Repository und GitHub herzustellen ist ein wichtiger Meilenstein, und ich zeige dir hier ausführlich, wie das funktioniert.

Das Grundprinzip verstehen

Bevor wir loslegen, ist es hilfreich zu verstehen, was hier eigentlich passiert:

flowchart LR
    LOCAL["📁 Lokales Repository\nauf deinem Computer"] -->|git push| REMOTE["☁️ Remote Repository\nauf GitHub"]
    REMOTE -->|git pull| LOCAL

Dein lokales Repository enthält bereits deine gesamte Commit-Historie. GitHub stellt dir einen Remote zur Verfügung – das ist im Grunde eine Kopie deines Repositories auf einem Server, mit der du dein lokales Repository synchronisieren kannst. Die Verbindung zwischen beiden nennt man Remote-Verknüpfung, und der Standard-Name für die Haupt-Remote ist origin.

Schritt 1: Ein neues Repository auf GitHub erstellen

Zunächst brauchst du ein „Zuhause" für deinen Code auf GitHub. Dieses Repository erstellst du direkt auf der GitHub-Website.

  1. Bei GitHub anmelden

    Öffne github.com und melde dich mit deinem Account an. Falls du noch keinen hast, musst du zuerst einen erstellen.

  2. Neues Repository anlegen

    Klicke oben rechts auf das +-Symbol und wähle New repository (oder gehe direkt zu github.com/new).

  3. Repository-Einstellungen festlegen

    Jetzt siehst du ein Formular mit mehreren Optionen:

    • Repository name: Wähle einen aussagekräftigen Namen für dein Projekt. Am besten verwendest du den gleichen Namen wie dein lokaler Projektordner – das ist zwar nicht zwingend notwendig, macht es aber übersichtlicher. Beispiel: mein-webprojekt

    • Description (optional): Eine kurze Beschreibung deines Projekts. Das ist besonders nützlich, wenn du das Repository später öffentlich machst oder selbst nach Monaten noch wissen willst, worum es geht.

    • Visibility – Public oder Private:

      • Public: Jeder kann dein Repository sehen (aber nur du kannst Änderungen pushen, solange du niemanden einlädst).
      • Private: Nur du und eingeladene Personen können das Repository sehen.

      Für persönliche Projekte oder Lernprojekte ist „Private" oft die bessere Wahl – du kannst es später jederzeit öffentlich machen.

    • Initialize this repository with… ⚠️ Wichtig:

      Da du bereits ein lokales Repository mit Commits hast, solltest du hier nichts auswählen:

      • ❌ Kein Häkchen bei „Add a README file"
      • ❌ Kein Häkchen bei „Add .gitignore"
      • ❌ Kein Häkchen bei „Choose a license"

      Warum? Wenn GitHub diese Dateien automatisch erstellt, hat das neue Remote-Repository bereits einen Commit. Dein lokales Repository hat aber eine andere Historie – und das führt zu Konflikten beim ersten Push. Ein komplett leeres Repository lässt sich dagegen problemlos mit deinem bestehenden lokalen Repository verbinden.

  4. Repository erstellen

    Klicke auf Create repository. GitHub erstellt das Repository und zeigt dir eine Seite mit Anleitungen – genau diese werden wir im nächsten Schritt nutzen.

Schritt 2: Die Remote-URL kopieren

Nach der Erstellung zeigt GitHub dir eine Seite mit verschiedenen Optionen. Da du bereits ein lokales Repository hast, interessiert dich der Abschnitt „…or push an existing repository from the command line".

Bevor du die Befehle ausführst, brauchst du die URL deines Repositories. GitHub bietet zwei Varianten an:

Protokoll URL-Format Wann verwenden
HTTPS https://github.com/benutzername/repo.git Einfacher Einstieg, aber du musst dich bei jedem Push authentifizieren (oder einen Credential Manager nutzen)
SSH git@github.com:benutzername/repo.git Empfohlen, wenn du SSH-Keys eingerichtet hast – keine Passwort-Eingabe nötig

Falls du SSH-Keys bereits eingerichtet hast (siehe Kapitel zu SSH-Keys), wähle SSH. Ansonsten funktioniert HTTPS genauso gut – du wirst dann beim ersten Push nach deinen GitHub-Zugangsdaten gefragt.

Klicke auf den entsprechenden Tab (HTTPS oder SSH) und kopiere die angezeigte URL.

Schritt 3: Remote in PhpStorm hinzufügen

Jetzt verbindest du dein lokales Repository mit dem frisch erstellten GitHub-Repository. Das machst du, indem du eine Remote hinzufügst.

Variante A: Über das PhpStorm-Menü (empfohlen für Einsteiger)

  1. Git-Menü öffnen

    Gehe in PhpStorm zu Git → Manage Remotes… (in älteren Versionen: VCS → Git → Remotes…).

  2. Neue Remote hinzufügen

    Es öffnet sich ein Dialog, der alle konfigurierten Remotes anzeigt – bei einem frischen lokalen Repository ist diese Liste leer.

    Klicke auf das +-Symbol, um eine neue Remote hinzuzufügen.

  3. Name und URL eingeben

    • Name: Gib origin ein. Das ist der Standardname für die Haupt-Remote und wird von Git und den meisten Tools erwartet.
    • URL: Füge die kopierte GitHub-URL ein (HTTPS oder SSH).

    Klicke auf OK.

  4. Fertig!

    Die Remote ist jetzt konfiguriert. PhpStorm weiß nun, wo dein Code auf GitHub „wohnt".

Variante B: Über das Terminal in PhpStorm

Falls du lieber mit Befehlen arbeitest, kannst du das integrierte Terminal nutzen:

  1. Öffne das Terminal in PhpStorm (View → Tool Windows → Terminal oder Alt + F12).

  2. Gib folgenden Befehl ein (ersetze die URL durch deine eigene):

    git remote add origin https://github.com/dein-benutzername/mein-webprojekt.git

    Oder mit SSH:

    git remote add origin git@github.com:dein-benutzername/mein-webprojekt.git

  3. Überprüfe, ob die Remote korrekt hinzugefügt wurde:

    git remote -v

    Du solltest so etwas sehen:

    origin  https://github.com/dein-benutzername/mein-webprojekt.git (fetch)
origin  https://github.com/dein-benutzername/mein-webprojekt.git (push)

Schritt 4: Den ersten Push durchführen

Jetzt kommt der spannende Moment: Du lädst deine gesamte lokale Commit-Historie auf GitHub hoch!

In PhpStorm (grafisch)

  1. Push-Dialog öffnen

    Gehe zu Git → Push… (oder nutze das Tastenkürzel Ctrl + Shift + K auf Windows/Linux bzw. Cmd + Shift + K auf macOS).

  2. Push-Vorschau prüfen

    PhpStorm zeigt dir an, welche Commits gepusht werden – das sollten alle deine bisherigen lokalen Commits sein.

    Du siehst auch, zu welchem Branch gepusht wird. Standardmäßig ist das main (oder master, je nach deiner Git-Konfiguration).

  3. Push ausführen

    Klicke auf Push. Falls du HTTPS verwendest und noch keine Zugangsdaten gespeichert hast, wirst du nach deinem GitHub-Benutzernamen und Passwort gefragt (oder nach einem Personal Access Token – dazu gleich mehr).

Im Terminal

Alternativ kannst du den Push auch über das Terminal durchführen:

git push -u origin main

💡 Was bedeutet -u?

Die Option -u (oder --set-upstream) sorgt dafür, dass Git sich merkt, dass dein lokaler main-Branch mit dem Remote-Branch origin/main verknüpft ist. Danach reicht ein einfaches git push ohne weitere Parameter.

Falls dein Hauptbranch master heißt (bei älteren Git-Versionen oder Projekten), ersetze main durch master.

Authentifizierung bei HTTPS: Personal Access Token (PAT)

Falls du HTTPS verwendest und GitHub nach einem Passwort fragt, funktioniert dein normales GitHub-Passwort nicht mehr für Git-Operationen. Stattdessen benötigst du einen Personal Access Token (PAT).

Einen PAT erstellen

  1. Gehe auf GitHub zu Settings → Developer settings → Personal access tokens → Tokens (classic) (oder direkt: github.com/settings/tokens).

  2. Klicke auf Generate new token (classic).

  3. Gib dem Token einen beschreibenden Namen (z. B. „PhpStorm auf Laptop").

  4. Wähle ein Ablaufdatum – für mehr Sicherheit empfiehlt sich ein begrenzter Zeitraum (z. B. 90 Tage), den du bei Bedarf verlängern kannst.

  5. Setze mindestens folgende Berechtigungen (Scopes):

    • ✅ repo – Vollzugriff auf Repositories (nötig für Push/Pull)

  6. Klicke auf Generate token und kopiere den Token sofort – er wird nur einmal angezeigt!

Den Token verwenden

Wenn PhpStorm (oder Git) nach dem Passwort fragt, gibst du statt deines GitHub-Passworts den Personal Access Token ein.

💡 Tipp: PhpStorm kann den Token speichern, sodass du ihn nicht jedes Mal neu eingeben musst. Achte darauf, dass in den Einstellungen unter Appearance & Behavior → System Settings → Passwords ein sicherer Speicherort konfiguriert ist (z. B. der Systemschlüsselbund).

Nach dem Push: Überprüfen, ob alles geklappt hat ✅

  1. Auf GitHub nachschauen

    Öffne dein Repository auf GitHub (z. B. https://github.com/dein-benutzername/mein-webprojekt). Du solltest jetzt alle deine Dateien und die gesamte Commit-Historie sehen können.

  2. In PhpStorm

    Öffne das Git-Log (Git → Show Git Log). Du siehst jetzt neben deinen lokalen Branches auch den Remote-Branch origin/main, der auf denselben Commit zeigt wie dein lokaler main.

Zusammenfassung des gesamten Ablaufs

Hier nochmal alle Schritte im Überblick:

flowchart TD
    A["1. Leeres Repository\nauf GitHub erstellen"] --> B["2. Remote-URL kopieren\nHTTPS oder SSH"]
    B --> C["3. Remote in PhpStorm\nhinzufuegen via\nGit > Manage Remotes"]
    C --> D["4. Ersten Push durchfuehren\nGit > Push"]
    D --> E["5. Auf GitHub pruefen\nob alles angekommen ist"]

Häufige Probleme und Lösungen

„Failed to push: rejected – non-fast-forward"

Dieser Fehler tritt auf, wenn das Remote-Repository bereits Commits enthält, die du lokal nicht hast (z. B. weil du bei der Erstellung versehentlich eine README-Datei hast anlegen lassen).

Lösung:

  1. Ziehe zuerst die Remote-Änderungen mit git pull origin main --allow-unrelated-histories
  2. Löse eventuelle Merge-Konflikte
  3. Committe und pushe erneut

Besser: Erstelle das GitHub-Repository wirklich komplett leer (ohne README, ohne .gitignore, ohne Lizenz).

„Permission denied (publickey)"

Dieser Fehler erscheint, wenn du SSH verwendest, aber dein SSH-Key nicht korrekt eingerichtet ist.

Lösung:

„Repository not found"

Entweder existiert das Repository nicht, der Name ist falsch geschrieben, oder du hast keine Zugriffsrechte (bei privaten Repositories).

Lösung:

Wie es danach weitergeht

Nach dem ersten Push ändert sich dein Workflow nur minimal:

  1. Lokal arbeiten und committen – wie bisher
  2. Regelmäßig pushen – um deine Änderungen auf GitHub zu sichern (Git → Push oder Ctrl + Shift + K)
  3. Bei Bedarf pullen – falls du von einem anderen Gerät aus gepusht hast oder mit anderen zusammenarbeitest (Git → Pull)

Die Verknüpfung zwischen lokalem und Remote-Repository bleibt dauerhaft bestehen – du musst die Remote-Konfiguration nur einmal pro Projekt durchführen. 🎉

Kapitel 7: Push, Pull und Synchronisation

Einleitung: Dein lokales Repository und das GitHub-Repository sind zwei separate Kopien deines Projekts. Sie synchronisieren sich nicht automatisch – du musst Git aktiv sagen, wann es Änderungen hochladen (Push) oder herunterladen (Pull) soll. Das klingt zunächst umständlich, gibt dir aber volle Kontrolle darüber, wann welche Änderungen wohin fließen. Besonders wichtig wird das, wenn du von mehreren Computern arbeitest oder mit anderen zusammenarbeitest: Dann können Konflikte entstehen, die du auflösen musst. Dieses Kapitel erklärt dir den Synchronisationsprozess und zeigt dir, wie du typische Probleme vermeidest, die Einsteiger oft frustrieren.

Kapitel 7: Push, Pull und Synchronisation

Push und Pull in Git – Daten zwischen lokal und remote synchronisieren 🔄

Wenn du dein lokales Repository mit GitHub (oder einem anderen Remote-Server) verbunden hast, brauchst du eine Möglichkeit, deine Änderungen hochzuladen und die Änderungen anderer (oder deine eigenen von einem anderen Gerät) herunterzuladen. Genau dafür gibt es Push und Pull – zwei der wichtigsten Befehle im Git-Alltag.

Das Grundkonzept verstehen

Stell dir dein lokales Repository und das Remote-Repository auf GitHub als zwei getrennte Kopien deines Projekts vor. Sie sind zwar miteinander verbunden, aber nicht automatisch synchron. Änderungen, die du lokal machst, existieren zunächst nur auf deinem Computer – und umgekehrt.

flowchart LR
    LOCAL["📁 Lokales Repository\nauf deinem Computer"] -->|git push| REMOTE["☁️ Remote Repository\nauf GitHub"]
    REMOTE -->|git pull| LOCAL
Befehl Richtung Was passiert?
Push Lokal → Remote Deine lokalen Commits werden auf GitHub hochgeladen
Pull Remote → Lokal Änderungen von GitHub werden auf deinen Computer heruntergeladen und integriert

Push – Deine Änderungen hochladen 📤

Wann benutze ich Push?

Du verwendest Push immer dann, wenn du:

💡 Wichtig: Push lädt nur Commits hoch, nicht einfach gespeicherte Dateien. Du musst also erst git add und git commit gemacht haben, bevor Push etwas zu übertragen hat.

Push in PhpStorm durchführen

  1. Stelle sicher, dass du Commits hast, die noch nicht gepusht wurden

    In der unteren Statusleiste von PhpStorm siehst du oft einen Hinweis wie „↑2" – das bedeutet, du hast zwei Commits, die noch nicht auf dem Remote sind.

  2. Push-Dialog öffnen

    Es gibt mehrere Wege:

    • Tastenkombination: Ctrl + Shift + K (Windows/Linux) oder Cmd + Shift + K (macOS)
    • Menü: Gehe zu Git → Push…
    • Toolbar: Klicke auf den grünen Pfeil nach oben in der Git-Toolbar

  3. Commits überprüfen

    Im Push-Dialog siehst du eine Liste aller Commits, die hochgeladen werden. Du kannst hier noch einmal prüfen, ob alles korrekt ist.

  4. Push ausführen

    Klicke auf Push. PhpStorm verbindet sich mit GitHub und lädt deine Commits hoch. Bei Erfolg siehst du eine Bestätigungsmeldung unten rechts.

Was kann schiefgehen?

Manchmal verweigert GitHub den Push mit einer Fehlermeldung wie „rejected – non-fast-forward". Das passiert, wenn auf dem Remote Änderungen existieren, die du lokal noch nicht hast. In diesem Fall musst du erst Pull ausführen, bevor du pushen kannst.

Pull – Änderungen herunterladen und integrieren 📥

Wann benutze ich Pull?

Du verwendest Pull immer dann, wenn du:

Was passiert bei einem Pull genau?

Ein git pull ist eigentlich eine Kombination aus zwei Befehlen:

flowchart LR
    A["git pull"] --> B["git fetch\nÄnderungen herunterladen"]
    B --> C["git merge\nÄnderungen integrieren"]
  1. Fetch: Git lädt die neuen Commits vom Remote herunter, ohne sie direkt anzuwenden
  2. Merge: Git integriert diese Commits in deinen aktuellen Branch

Pull in PhpStorm durchführen

  1. Pull-Dialog öffnen

    • Tastenkombination: Ctrl + T (Windows/Linux) oder Cmd + T (macOS)
    • Menü: Gehe zu Git → Pull…
    • Toolbar: Klicke auf den blauen Pfeil nach unten in der Git-Toolbar

  2. Optionen prüfen

    Im Pull-Dialog siehst du:

    • Remote: Normalerweise „origin" (dein GitHub-Repository)
    • Branch: Der Branch, von dem du pullen möchtest (meist der gleiche wie dein aktueller)
    • Update Type: Hier kannst du zwischen „Merge" und „Rebase" wählen – als Anfänger bleib bei der Standardeinstellung (Merge)

  3. Pull ausführen

    Klicke auf Pull. PhpStorm lädt die Änderungen herunter und integriert sie.

Die schnelle Alternative: Update Project

PhpStorm bietet auch eine komfortablere Option namens Update Project:

Diese Option prüft automatisch, ob Änderungen vorhanden sind, und führt den Pull durch. Du wirst gefragt, ob du „Merge" oder „Rebase" verwenden möchtest – wähle als Anfänger Merge.

Push und Pull im Vergleich – eine Übersicht

Aspekt Push 📤 Pull 📥
Richtung Lokal → Remote Remote → Lokal
Zweck Eigene Commits hochladen Fremde/andere Commits herunterladen
Tastenkürzel Ctrl/Cmd + Shift + K Ctrl/Cmd + T
Voraussetzung Du musst Commits haben Es müssen Änderungen auf dem Remote sein
Kann Konflikte verursachen? Nein (wird ggf. abgelehnt) Ja (bei gleichzeitigen Änderungen)

Ein typischer Arbeitsablauf in der Praxis

Hier ist ein Beispiel, wie Push und Pull in deinen normalen Workflow passen:

flowchart TD
    A["🌅 Arbeitstag beginnen"] --> B["Pull ausführen\nNeueste Änderungen holen"]
    B --> C["An Dateien arbeiten\nCode schreiben"]
    C --> D["Änderungen stagen\nund committen"]
    D --> E{"Weitere Arbeit\ngeplant?"}
    E -->|Ja| C
    E -->|Nein| F["Push ausführen\nÄnderungen hochladen"]
    F --> G["🌙 Feierabend"]

Merke dir diese Faustregel:

„Pull am Anfang, Push am Ende" – Hole dir zu Beginn einer Arbeitssession immer die neuesten Änderungen und lade deine Arbeit am Ende hoch.

Häufige Situationen und wie du damit umgehst

Situation 1: Push wird abgelehnt

Problem: Du versuchst zu pushen, aber Git sagt „rejected" oder „non-fast-forward".

Lösung:

  1. Führe zuerst einen Pull aus
  2. Löse eventuelle Merge-Konflikte (falls vorhanden)
  3. Versuche den Push erneut

Situation 2: Pull verursacht Merge-Konflikte

Problem: Beim Pull meldet PhpStorm, dass es Konflikte gibt.

Lösung: PhpStorm öffnet automatisch den Merge-Tool-Dialog. Dort kannst du für jede konfliktbehaftete Datei entscheiden, welche Version du behalten möchtest – oder beide manuell zusammenführen. (Details dazu findest du im Kapitel zu Merge-Konflikten.)

Situation 3: Du möchtest nur schauen, ob es Änderungen gibt

Problem: Du willst wissen, ob auf GitHub neue Commits sind, ohne sie direkt zu integrieren.

Lösung: Verwende Fetch statt Pull:

Zusammenfassung ✅

Kapitel 7: Push, Pull und Synchronisation

Push-Konflikte: Wenn GitHub „ahead" ist 🚧

Du möchtest deine lokalen Commits auf GitHub pushen, aber Git verweigert das mit einer Fehlermeldung. Das passiert, wenn das Remote-Repository neuere Commits enthält, die du lokal noch nicht hast. Diese Situation ist völlig normal und gehört zum Git-Alltag – besonders wenn du an mehreren Geräten arbeitest oder mit anderen zusammenarbeitest.

Warum lehnt Git den Push ab?

Git hat eine wichtige Schutzfunktion: Es verhindert, dass du versehentlich Änderungen auf dem Server überschreibst, die du noch gar nicht gesehen hast. Wenn das Remote-Repository Commits enthält, die in deiner lokalen Historie fehlen, sagt Git sinngemäß:

„Stopp! Auf dem Server gibt es neuere Änderungen. Hol dir die erst, bevor du deine eigenen hochlädst."

Die typische Fehlermeldung sieht ungefähr so aus:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:username/repo.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

Das folgende Diagramm zeigt, wie diese Situation entsteht:

flowchart TB
    subgraph LOCAL["💻 Dein lokaler Stand"]
        L1["Commit A"] --> L2["Commit B"] --> L3["Commit C\n- deine neue Arbeit"]
    end
    
    subgraph REMOTE["☁️ GitHub-Stand"]
        R1["Commit A"] --> R2["Commit B"] --> R3["Commit X\n- andere Aenderung"]
    end
    
    L3 -.->|"Push verweigert!"| R3

Du bist bei Commit C, aber GitHub hat in der Zwischenzeit Commit X bekommen. Git weiß nicht, wie es diese beiden zusammenbringen soll, ohne dass du es ihm sagst.

Die Lösung: Erst Pull, dann Push

Der Standard-Workflow in dieser Situation ist einfach:

  1. Hole die Remote-Änderungen mit git pull
  2. Löse eventuelle Konflikte (falls dieselben Stellen geändert wurden)
  3. Pushe dann erneut deine kombinierten Änderungen

In PhpStorm durchführen

  1. Pull durchführen

    Gehe zu Git → Pull (oder drücke Ctrl+T bzw. Cmd+T auf macOS). PhpStorm zeigt dir ein Dialogfenster, in dem du den Remote-Branch auswählen kannst – normalerweise ist das schon korrekt voreingestellt.

  2. Ergebnis prüfen

    Nach dem Pull gibt es drei mögliche Szenarien:

    • Alles automatisch zusammengeführt: Git konnte die Änderungen problemlos kombinieren. Du siehst eine Erfolgsmeldung und kannst direkt pushen.
    • Merge-Commit erstellt: Wenn die Änderungen in unterschiedlichen Dateien oder an unterschiedlichen Stellen waren, erstellt Git automatisch einen „Merge-Commit", der beide Historien zusammenführt.
    • Konflikte aufgetreten: Wenn dieselben Zeilen in derselben Datei geändert wurden, musst du manuell entscheiden, welche Version gilt (siehe unten).

  3. Push erneut versuchen

    Nach erfolgreichem Pull gehst du zu Git → Push (oder Ctrl+Shift+K bzw. Cmd+Shift+K). Jetzt sollte der Push funktionieren.

Was passiert beim Pull genau?

Hinter den Kulissen macht git pull eigentlich zwei Dinge:

flowchart LR
    A["git pull"] --> B["git fetch\n- Aenderungen herunterladen"]
    B --> C["git merge\n- Aenderungen integrieren"]

Nach einem erfolgreichen Pull sieht deine Historie so aus:

flowchart TB
    A["Commit A"] --> B["Commit B"]
    B --> C["Commit C\n- deine Arbeit"]
    B --> X["Commit X\n- andere Aenderung"]
    C --> M["Merge-Commit\n- beide zusammengefuehrt"]
    X --> M

Wenn Konflikte auftreten

Falls du und die andere Änderung (oder du selbst vom anderen Computer) dieselben Codezeilen bearbeitet habt, kann Git nicht automatisch entscheiden, welche Version richtig ist. PhpStorm zeigt dir dann den Merge-Dialog:

  1. Konflikt-Benachrichtigung

    PhpStorm meldet, dass Konflikte aufgetreten sind und fragt, ob du sie lösen möchtest. Klicke auf Merge oder Resolve.

  2. Drei-Spalten-Editor nutzen

    Du siehst drei Spalten nebeneinander:

    • Links: Deine lokale Version
    • Rechts: Die Version von GitHub
    • Mitte: Das Ergebnis, das du erstellen möchtest

    Mit den Pfeiltasten (>> und <<) oder durch direktes Bearbeiten in der Mitte kannst du entscheiden, welche Änderungen übernommen werden.

  3. Konflikt als gelöst markieren

    Sobald du fertig bist, klickst du auf Apply. PhpStorm markiert den Konflikt als gelöst.

  4. Merge-Commit abschließen

    Nachdem alle Konflikte gelöst sind, fordert PhpStorm dich auf, den Merge-Commit abzuschließen. Bestätige dies, und dann kannst du pushen.

Alternative: Rebase statt Merge

Neben dem klassischen Merge gibt es noch eine andere Strategie namens Rebase. Dabei werden deine lokalen Commits so umgeschrieben, als hättest du sie nach den Remote-Änderungen gemacht. Das ergibt eine lineare Historie ohne Merge-Commits:

flowchart LR
    A["Commit A"] --> B["Commit B"] --> X["Commit X\n- von GitHub"] --> C2["Commit C\n- deine Arbeit, neu aufgesetzt"]

Rebase in PhpStorm aktivieren

  1. Gehe zu Git → Pull
  2. Im Pull-Dialog aktiviere die Option Rebase (statt Merge)
  3. Führe den Pull durch

Oder du stellst es als Standard ein unter Settings → Version Control → Git → Update Method → Rebase.

Wann Rebase, wann Merge?

Situation Empfehlung
Du arbeitest allein oder an einem Feature-Branch Rebase – für eine saubere, lineare Historie
Mehrere Personen arbeiten am selben Branch Merge – sicherer, da keine Historie umgeschrieben wird
Du hast den Branch bereits gepusht und andere arbeiten damit Merge – Rebase würde deren Arbeit durcheinanderbringen
Du bist unsicher Merge – es ist die sichere Standardoption

Tipps zur Vermeidung dieser Situation

Auch wenn die Lösung nicht schwer ist, kannst du dir das Leben leichter machen:

Zusammenfassung

Problem Lösung
Push wird abgelehnt wegen neuerer Remote-Commits git pull durchführen, dann erneut pushen
Pull führt zu Konflikten Konflikte in PhpStorm mit dem Drei-Spalten-Editor lösen
Du möchtest eine lineare Historie Rebase statt Merge beim Pull verwenden

Der Ablauf ist also immer: Pull → (Konflikte lösen) → Push. Mit etwas Routine wird das schnell zur Gewohnheit, und du wirst sehen, dass diese Situationen viel weniger beängstigend sind, als sie anfangs wirken. 😊

Kapitel 7: Push, Pull und Synchronisation

Der Unterschied zwischen git fetch und git pull 🔄

Beide Befehle holen Daten von einem Remote-Repository (z. B. GitHub), aber sie tun es auf sehr unterschiedliche Weise. Das zu verstehen hilft dir, in verschiedenen Situationen die richtige Entscheidung zu treffen – und verhindert unerwartete Überraschungen in deinem Code.

Das Grundprinzip

Um den Unterschied zu verstehen, ist es wichtig zu wissen, dass Git zwei Dinge getrennt voneinander betrachtet:

  1. Die Informationen über den Zustand des Remote-Repositories – also welche Commits dort existieren
  2. Den tatsächlichen Zustand deiner lokalen Arbeitsdateien – also dein Working Directory und dein lokaler Branch
flowchart TB
    subgraph Remote ["☁️ GitHub"]
        RC["Remote Commits"]
    end
    
    subgraph Lokal ["💻 Dein Computer"]
        TRACK["Remote-Tracking Branch\n(origin/main)"]
        LOCAL["Lokaler Branch\n(main)"]
        WD["Working Directory\nDeine Dateien"]
    end
    
    RC -->|git fetch| TRACK
    TRACK -->|git merge| LOCAL
    LOCAL --> WD
    RC -->|git pull| TRACK
    RC -->|git pull| LOCAL
    RC -->|git pull| WD

git fetch – nur informieren, nichts verändern

Mit git fetch holst du dir die neuesten Informationen vom Remote-Repository, aber deine lokalen Branches und Dateien bleiben komplett unverändert. Git aktualisiert lediglich die sogenannten Remote-Tracking-Branches (z. B. origin/main), die wie ein Spiegel des Remote-Zustands funktionieren.

Was passiert konkret?

Typische Ausgabe nach git fetch:

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
From github.com:username/projekt
   a1b2c3d..e4f5g6h  main     -> origin/main

Das sagt dir: „Es gibt neue Commits auf GitHub, ich habe sie in origin/main gespeichert, aber dein lokaler main ist noch auf dem alten Stand."

git pull – informieren und integrieren

git pull ist im Grunde zwei Befehle in einem:

$$
\texttt{git pull} = \texttt{git fetch} + \texttt{git merge}
$$

Es holt also nicht nur die Informationen, sondern führt die Änderungen auch direkt in deinen aktuellen Branch ein. Deine lokalen Dateien werden entsprechend aktualisiert.

Was passiert konkret?

  1. Git führt zunächst einen fetch durch
  2. Anschließend werden die neuen Commits automatisch in deinen lokalen Branch gemergt
  3. Dein Working Directory wird aktualisiert – du siehst die Änderungen sofort in deinen Dateien

Typische Ausgabe nach git pull:

remote: Enumerating objects: 5, done.
From github.com:username/projekt
   a1b2c3d..e4f5g6h  main     -> origin/main
Updating a1b2c3d..e4f5g6h
Fast-forward
 src/login.php | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

Wann welchen Befehl verwenden?

Situation Empfohlener Befehl Begründung
Du möchtest nur schauen, ob es etwas Neues gibt git fetch Keine Änderungen an deinem Code, du behältst die Kontrolle
Du hast ungespeicherte Arbeit und willst nichts riskieren git fetch Kein Risiko von Merge-Konflikten mitten in der Arbeit
Du möchtest die Unterschiede analysieren, bevor du aktualisierst git fetch + manueller Vergleich Du kannst origin/main mit deinem main vergleichen
Du bist bereit, die neuesten Änderungen zu übernehmen git pull Schnell und praktisch, wenn du weißt, was kommt
Du startest frisch in den Arbeitstag und willst auf dem aktuellen Stand sein git pull Holt alles und bringt dich auf den neuesten Stand
Du arbeitest im Team und bist unsicher, was andere geändert haben git fetch zuerst Gibt dir die Möglichkeit, Änderungen zu prüfen

💡 Faustregel: Im Zweifel ist git fetch die „sicherere" Wahl, weil es deine lokale Arbeit nicht antastet. Du kannst danach immer noch entscheiden, ob und wann du die Änderungen übernimmst.

Der typische Workflow mit git fetch

Wenn du vorsichtig vorgehen möchtest, sieht ein typischer Ablauf so aus:

  1. Fetch ausführen – Hole die neuesten Informationen:

    git fetch

  2. Vergleichen – Schau dir an, was sich geändert hat:

    git log main..origin/main --oneline

    Das zeigt dir alle Commits, die auf origin/main sind, aber noch nicht in deinem lokalen main.

  3. Entscheiden und mergen – Wenn alles gut aussieht:

    git merge origin/main

So machst du es in PhpStorm

PhpStorm bietet dir beide Optionen komfortabel über die Benutzeroberfläche an.

Fetch in PhpStorm

  1. Gehe im Menü zu Git → Fetch (oder nutze die Tastenkombination, die du in den Einstellungen findest)
  2. PhpStorm verbindet sich mit GitHub und aktualisiert die Remote-Tracking-Branches
  3. Im Git-Log (unten im Git-Tool-Fenster) siehst du nun, ob origin/main weiter ist als dein lokaler main
  4. Du erkennst das an einer Anzeige wie „main ← 3 commits behind origin/main"

Pull in PhpStorm

  1. Gehe im Menü zu Git → Pull (oder klicke auf den blauen Pfeil nach unten in der Toolbar)
  2. Es öffnet sich ein Dialog, in dem du auswählen kannst:
    • Von welchem Remote du pullen möchtest (normalerweise origin)
    • Welchen Branch du holen möchtest
    • Ob du einen Merge oder Rebase verwenden willst (als Anfänger: bleib bei Merge)
  3. Klicke auf Pull, und PhpStorm holt die Änderungen und integriert sie

Update Project – die komfortable Alternative

PhpStorm bietet auch die Option Git → Update Project (oder Ctrl+T / Cmd+T). Diese öffnet einen Dialog, der dir verschiedene Optionen gibt:

Was passiert bei Konflikten?

Sowohl nach git pull als auch nach einem manuellen git merge (nach fetch) kann es zu Merge-Konflikten kommen, wenn dieselben Stellen in einer Datei unterschiedlich geändert wurden.

PhpStorm zeigt dir Konflikte im Merge-Tool an und hilft dir, sie visuell zu lösen – das kennst du vielleicht schon aus dem Kapitel zu Merge-Konflikten.

Zusammenfassung

Aspekt git fetch git pull
Holt Daten vom Remote ✅ Ja ✅ Ja
Ändert deinen lokalen Branch ❌ Nein ✅ Ja
Ändert deine Arbeitsdateien ❌ Nein ✅ Ja
Kann Merge-Konflikte auslösen ❌ Nein ✅ Ja, möglich
Risiko für laufende Arbeit 🟢 Keins 🟡 Mittel
Kontrolle über den Prozess 🟢 Volle Kontrolle 🟡 Automatisiert

🎯 Merke dir: git fetch ist wie „Nachrichten lesen, ohne zu antworten" – du informierst dich, ohne dich festzulegen. git pull ist wie „Nachrichten lesen und sofort darauf reagieren" – praktisch, aber du solltest wissen, was dich erwartet.

Kapitel 8: Fehler rückgängig machen 🆘

Einleitung: Fehler passieren – und genau dafür ist Git gemacht! Die Fähigkeit, Änderungen rückgängig zu machen, ist einer der größten Vorteile der Versionsverwaltung. Allerdings gibt es verschiedene Arten von „Rückgängig", abhängig davon, in welchem Stadium sich deine Änderungen befinden: noch nicht gestaged, gestaged aber nicht committed, committed aber nicht gepusht, oder bereits gepusht. Jede Situation erfordert einen anderen Ansatz. Besonders heikel wird es, wenn du versehentlich sensible Daten wie Passwörter committed hast – hier reicht einfaches Löschen nicht aus, da Git die Historie aufbewahrt. Dieses Kapitel gibt dir das Werkzeug, um aus jeder Situation wieder herauszukommen.

Kapitel 8: Fehler rückgängig machen 🆘

Änderungen rückgängig machen in PhpStorm – vor dem Commit 🔄

Du hast an einer oder mehreren Dateien gearbeitet, aber die Änderungen gefallen dir nicht oder du hast dich verrannt? Kein Problem – solange du noch nicht committed hast, kannst du deine Dateien ganz einfach auf den letzten gespeicherten Stand im Repository zurücksetzen. PhpStorm bietet dafür eine komfortable Funktion namens Rollback.

Das Konzept verstehen

Wenn du Änderungen an Dateien vornimmst, befinden sich diese zunächst im Working Directory – also deinem Arbeitsbereich. Git weiß, dass die Dateien verändert wurden (sie erscheinen als „modified"), aber diese Änderungen sind noch nicht Teil der Versionshistorie.

Der Befehl, den du im Terminal verwenden würdest, heißt git checkout -- <datei> oder in neueren Git-Versionen git restore <datei>. In PhpStorm musst du dir diese Befehle aber nicht merken – du nutzt einfach die Rollback-Funktion.

flowchart LR
    A["Datei im Working Directory\ngeaendert"] -->|Rollback| B["Datei zurueckgesetzt\nauf letzten Commit-Stand"]
    A -->|Ohne Rollback| C["Aenderung bleibt\nbis zum naechsten Commit"]

⚠️ Wichtig: Wenn du eine Datei zurücksetzt, sind die Änderungen unwiderruflich verloren – es gibt kein „Undo" für den Rollback selbst. Überlege also kurz, ob du die Änderungen wirklich verwerfen möchtest.

Eine einzelne Datei zurücksetzen

Wenn du nur eine bestimmte Datei auf den letzten Commit-Stand zurücksetzen möchtest, hast du in PhpStorm mehrere Möglichkeiten:

Über das Kontextmenü im Projektbaum

  1. Navigiere im Project-Panel (links) zu der Datei, deren Änderungen du verwerfen möchtest. Geänderte Dateien sind farblich markiert – typischerweise in Blau für modifizierte Dateien.

  2. Rechtsklick auf die Datei und wähle im Kontextmenü Git → Rollback… (in älteren Versionen eventuell unter Local History → Revert).

  3. Es öffnet sich ein Dialog, der dir die Änderungen anzeigt, die zurückgesetzt werden. Bestätige mit Rollback.

Über das Commit-Fenster

  1. Öffne das Commit-Tool-Fenster mit Ctrl + K (Windows/Linux) bzw. Cmd + K (macOS) oder über Git → Commit…

  2. Im Commit-Fenster siehst du links eine Liste aller geänderten Dateien. Rechtsklick auf die Datei, die du zurücksetzen möchtest.

  3. Wähle Rollback… aus dem Kontextmenü.

  4. Bestätige den Dialog – die Datei wird auf den Stand des letzten Commits zurückgesetzt.

Direkt im Editor

Wenn du die betreffende Datei gerade geöffnet hast, kannst du auch über das Menü gehen:

  1. Gehe zu Git → Rollback… (oder VCS → Git → Rollback… in älteren Versionen)

  2. PhpStorm zeigt dir einen Dialog mit allen geänderten Dateien. Wähle nur die Datei aus, die du zurücksetzen möchtest (andere Häkchen entfernen).

  3. Klicke auf Rollback.

Alle Änderungen auf einmal zurücksetzen

Manchmal möchtest du einen kompletten „Reset" machen und alle nicht-committeten Änderungen verwerfen. Auch das ist in PhpStorm schnell erledigt:

  1. Öffne das Commit-Fenster mit Ctrl + K / Cmd + K.

  2. Du siehst die Liste aller geänderten Dateien. Markiere alle Dateien, die du zurücksetzen möchtest (mit Ctrl + A / Cmd + A kannst du alle auswählen).

  3. Rechtsklick auf die Auswahl und wähle Rollback…

  4. Bestätige den Dialog – alle ausgewählten Dateien werden auf den letzten Commit-Stand zurückgesetzt.

Alternativ kannst du auch direkt über das Menü gehen:

  1. Gehe zu Git → Rollback…
  2. Im Dialog sind standardmäßig alle geänderten Dateien ausgewählt
  3. Klicke auf Rollback, um alles zurückzusetzen

Was ist mit bereits gestageten Dateien?

Wenn du Dateien bereits zur Staging Area hinzugefügt hast (also mit git add oder in PhpStorm durch Anhaken im Commit-Dialog), funktioniert der Rollback trotzdem – PhpStorm entfernt die Datei aus der Staging Area und setzt sie auf den letzten Commit-Stand zurück.

Falls du eine Datei nur aus der Staging Area entfernen möchtest, aber die Änderungen im Working Directory behalten willst, ist das ein anderer Fall: Dann entfernst du einfach das Häkchen bei der Datei im Commit-Dialog, ohne einen Rollback zu machen.

Zusammenfassung der Schritte

Was du tun möchtest So geht's in PhpStorm
Eine Datei zurücksetzen Rechtsklick auf Datei → Git → Rollback…
Alle Änderungen zurücksetzen Ctrl/Cmd + K → alle auswählen → Rechtsklick → Rollback…
Aus Staging entfernen (Änderungen behalten) Im Commit-Dialog das Häkchen bei der Datei entfernen

Der Unterschied zu „Revert Commit"

Verwechsle Rollback nicht mit Revert:

Wenn du also Änderungen rückgängig machen willst, die du schon committed hast, brauchst du einen anderen Ansatz – aber das ist ein Thema für ein anderes Kapitel. 😉

Kapitel 8: Fehler rückgängig machen 🆘

Commits rückgängig machen: reset vs. revert 🔄

Du hast also einen oder mehrere Commits gemacht, die du loswerden möchtest – vielleicht war ein Fehler dabei, oder du hast dich in eine falsche Richtung entwickelt. Git bietet dafür zwei grundlegend verschiedene Strategien: Reset und Revert. Welche du wählen solltest, hängt entscheidend davon ab, ob du die Commits bereits gepusht hast oder nicht.

Das Grundprinzip verstehen

Bevor wir in die Details gehen, hier die Kernfrage, die du dir immer stellen solltest:

Haben andere Menschen (oder ich selbst auf einem anderen Gerät) bereits Zugriff auf diese Commits?

Diese Frage bestimmt, welchen Weg du gehen solltest:

flowchart TD
    A["Commit rueckgaengig machen?"] --> B{"Bereits gepusht?"}
    B -->|Nein| C["git reset\nHistorie umschreiben"]
    B -->|Ja| D["git revert\nNeuen Commit erstellen"]
    
    C --> E["Commits verschwinden\naus der Historie"]
    D --> F["Alter Commit bleibt,\nwird durch neuen rueckgaengig gemacht"]
    
    style C fill:#90EE90,color:#000000
    style D fill:#87CEEB,color:#000000

Methode 1: git reset – die Historie umschreiben ✂️

Mit reset entfernst du Commits aus deiner lokalen Historie, als hätten sie nie existiert. Das ist sauber und elegant – aber nur, solange niemand sonst diese Commits bereits hat.

Die drei Varianten von Reset

Git reset gibt es in drei „Härtegraden", die bestimmen, was mit deinen Änderungen passiert:

  1. --soft – der sanfte Reset

    Die Commits werden entfernt, aber alle Änderungen bleiben in der Staging Area erhalten. Du kannst sie direkt neu committen (z. B. mit einer besseren Nachricht oder anders aufgeteilt).

    git reset --soft HEAD~1    # Letzten Commit entfernen, Änderungen bleiben staged

  2. --mixed (Standard) – der mittlere Weg

    Die Commits werden entfernt, die Änderungen landen im Working Directory (also nicht mehr staged, aber noch vorhanden). Du kannst entscheiden, was du davon behalten möchtest.

    git reset HEAD~1           # Letzten Commit entfernen, Änderungen im Working Directory
git reset --mixed HEAD~1   # Identisch zur Zeile darüber

  3. --hard – der radikale Reset ⚠️

    Die Commits werden entfernt und alle Änderungen werden unwiderruflich gelöscht. Hier ist Vorsicht geboten!

    git reset --hard HEAD~1    # Letzten Commit UND alle Änderungen komplett löschen

Was bedeutet HEAD~1?

Reset in PhpStorm durchführen

  1. Öffne das Git-Log (unten im Git-Tab)
  2. Finde den Commit, zu dem du zurückkehren möchtest (also den letzten „guten" Commit)
  3. Rechtsklick auf diesen Commit
  4. Wähle Reset Current Branch to Here...
  5. Im Dialog wählst du zwischen Soft, Mixed oder Hard

💡 Tipp: In PhpStorm siehst du direkt eine Erklärung zu jeder Option, was sehr hilfreich ist.

Methode 2: git revert – sicher rückgängig machen 🛡️

Mit revert erstellst du einen neuen Commit, der die Änderungen eines früheren Commits rückgängig macht. Die ursprünglichen Commits bleiben in der Historie erhalten – es wird nur ein „Gegengift" hinzugefügt.

Warum Revert statt Reset bei gepushten Commits?

Wenn du Commits gepusht hast und dann mit reset deine lokale Historie umschreibst, entsteht ein Problem: Dein lokales Repository und das Remote-Repository haben dann unterschiedliche Historien. Git wird sich weigern, deinen Push zu akzeptieren, und du müsstest einen Force Push machen – was die Historie für alle anderen zerstört, die vielleicht schon mit diesen Commits arbeiten.

revert vermeidet dieses Problem elegant:

flowchart LR
    subgraph "Nach Reset - GEFÄHRLICH"
        A1["Commit A"] --> A2["Commit B"] --> A3["Commit C"]
        A1 -.->|"reset"| A4["Commit C\nverschwunden"]
    end
    
    subgraph "Nach Revert - SICHER"
        B1["Commit A"] --> B2["Commit B"] --> B3["Commit C"] --> B4["Revert C\nmacht C rueckgaengig"]
    end

Revert im Terminal

# Den letzten Commit rückgängig machen
git revert HEAD

# Einen bestimmten Commit rückgängig machen (per Hash)
git revert abc1234

# Mehrere Commits auf einmal revert (ältester..neuester)
git revert abc1234..def5678

Nach dem Revert öffnet sich normalerweise ein Editor für die Commit-Nachricht. Git schlägt automatisch etwas wie „Revert ‚Feature XY hinzugefügt'" vor, was du anpassen oder übernehmen kannst.

Revert in PhpStorm durchführen

  1. Öffne das Git-Log
  2. Finde den Commit, den du rückgängig machen möchtest
  3. Rechtsklick auf den Commit
  4. Wähle Revert Commit
  5. PhpStorm erstellt automatisch einen neuen Commit, der die Änderungen umkehrt

Wann welche Methode? – Die Entscheidungshilfe

Situation Empfohlene Methode Begründung
Commit noch nicht gepusht, du möchtest neu committen reset --soft Änderungen bleiben staged, du kannst sie direkt verbessern
Commit noch nicht gepusht, du möchtest alles überdenken reset --mixed Änderungen im Working Directory, du wählst neu aus
Commit noch nicht gepusht, Änderungen sollen weg reset --hard Schnell und sauber, aber unwiderruflich
Commit bereits gepusht revert Sicher, keine Probleme mit Remote
Alte Commits mitten in der Historie korrigieren revert Historie bleibt intakt
Gemeinsames Projekt mit anderen Immer revert Teamkollegen werden es dir danken

Der Sonderfall: Force Push ⚠️

Falls du trotzdem nach einem Reset pushen möchtest (weil du z. B. allein am Projekt arbeitest und sicher bist, dass niemand sonst betroffen ist), kannst du einen Force Push machen:

git push --force
# oder etwas sicherer:
git push --force-with-lease

In PhpStorm findest du diese Option im Push-Dialog unter Force Push.

⚠️ Wichtig: Force Push überschreibt die Remote-Historie unwiderruflich. Nutze das nur, wenn du absolut sicher bist, dass niemand anderes mit diesen Commits arbeitet. In Team-Projekten ist Force Push auf den Main-Branch oft sogar verboten.

Die Option --force-with-lease ist etwas sicherer: Sie verweigert den Push, falls jemand anderes in der Zwischenzeit gepusht hat.

Praktisches Beispiel: Der typische „Oh nein"-Moment

Szenario: Du hast gerade einen Commit gemacht und gepusht, der versehentlich Debug-Code enthält.

  1. Prüfen, was passiert ist:

    Schau im Git-Log, welcher Commit das Problem verursacht hat (notiere dir den Hash, z. B. a1b2c3d).

  2. Revert durchführen:

    git revert a1b2c3d

    Oder in PhpStorm: Rechtsklick auf den Commit → Revert Commit

  3. Den Revert-Commit pushen:

    git push

  4. Fertig! Die Debug-Änderungen sind rückgängig gemacht, und die Historie zeigt transparent, was passiert ist.

Zusammenfassung 📋

Kapitel 8: Fehler rückgängig machen 🆘

Sensible Daten aus Git entfernen – warum einfaches Löschen nicht reicht 🔐

Du hast versehentlich ein Passwort, einen API-Key oder andere sensible Daten committed und vielleicht sogar auf GitHub gepusht. Das ist ein ernstes Problem, aber es lässt sich beheben – allerdings nicht durch einfaches Löschen der Datei in einem neuen Commit.

Warum reicht es nicht, die Datei einfach zu löschen?

Hier liegt ein fundamentales Missverständnis über Git vor, das vielen Anfängern passiert: Git vergisst nichts. Wenn du eine Datei mit einem Passwort commitest und sie dann im nächsten Commit löschst, ist das Passwort nicht weg – es steckt immer noch im alten Commit.

Jeder, der Zugriff auf dein Repository hat (oder hatte), kann:

💡 Merke: Ein Commit ist wie ein Foto deines gesamten Projekts zu einem bestimmten Zeitpunkt. Auch wenn du die Datei später löschst, existiert das alte „Foto" mit der Datei noch immer in der Historie.

Das bedeutet: Sensible Daten sind kompromittiert, sobald sie gepusht wurden – selbst wenn du sie Sekunden später „löschst".

Was du wirklich tun musst

Die Lösung erfordert mehrere Schritte, und die Reihenfolge ist wichtig:

1. Sofort das kompromittierte Geheimnis ungültig machen 🚨

Das ist der allerwichtigste Schritt und sollte sofort passieren:

⚠️ Geh davon aus, dass das Geheimnis bereits kompromittiert ist! Bots scannen GitHub kontinuierlich nach Zugangsdaten. Innerhalb von Minuten nach dem Push können deine Daten bereits missbraucht worden sein.

2. Die Git-Historie bereinigen

Nachdem du das Geheimnis ungültig gemacht hast, solltest du es auch aus der Git-Historie entfernen – nicht weil es dadurch wieder sicher wird (das Geheimnis ist bereits kompromittiert), sondern um zu verhindern, dass es bei zukünftigen Clones oder Forks weiter verbreitet wird.

Methode A: Mit git filter-repo (empfohlen)

Das Tool git filter-repo ist der moderne, sichere Weg, um Dateien oder Inhalte aus der gesamten Git-Historie zu entfernen:

  1. Tool installieren

    # Mit pip (Python)
pip install git-filter-repo

# Oder über Paketmanager (z.B. Homebrew auf macOS)
brew install git-filter-repo

  2. Datei aus der gesamten Historie entfernen

    # Entfernt die Datei "config/secrets.php" aus ALLEN Commits
git filter-repo --path config/secrets.php --invert-paths

  3. Änderungen auf GitHub pushen

    # Force-Push, weil du die Historie umgeschrieben hast
git push origin --force --all

Methode B: Mit BFG Repo-Cleaner (einfacher für Anfänger)

Der BFG Repo-Cleaner ist speziell dafür entwickelt, sensible Daten zu entfernen:

  1. BFG herunterladen (eine .jar-Datei)

  2. Passwörter aus der Historie entfernen

    # Erstelle eine Datei mit den zu entfernenden Texten
echo "meinGeheimesPasswort123" > passwords.txt

# BFG ausführen
java -jar bfg.jar --replace-text passwords.txt mein-repo.git

  3. Bereinigung abschließen und pushen

    cd mein-repo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push origin --force --all

3. GitHub-Cache invalidieren

Auch nach dem Force-Push können alte Commits noch über ihre SHA-Hashes erreichbar sein, wenn jemand die URL kennt. GitHub bietet eine Möglichkeit, diese zu entfernen:

  1. Kontaktiere den GitHub-Support über support.github.com
  2. Bitte um die Entfernung gecachter Ansichten der betroffenen Commits
  3. Wenn das Repository geforkt wurde, müssen auch die Forks bereinigt werden

4. Alle Mitwirkenden informieren

Wenn andere Personen das Repository geklont haben, müssen sie:

⚠️ Wenn jemand einen alten Klon hat und pusht, könnten die sensiblen Daten wieder ins Repository gelangen!

Zusammenfassung als Checkliste

flowchart TD
    A["Sensible Daten\ngepusht!"] --> B["1. Geheimnis SOFORT\nungueltigt machen"]
    B --> C["Passwort aendern\nAPI-Key rotieren\nToken widerrufen"]
    C --> D["2. Git-Historie\nbereinigen"]
    D --> E["git filter-repo\noder BFG verwenden"]
    E --> F["3. Force-Push\nauf GitHub"]
    F --> G["4. GitHub-Support\nkontaktieren"]
    G --> H["5. Team informieren\nNeu-Clone erforderlich"]
    
    style A fill:#ff6b6b,color:#000
    style B fill:#ffd93d,color:#000
    style C fill:#ffd93d,color:#000
Schritt Aktion Priorität
1 Geheimnis ungültig machen 🔴 Sofort
2 Historie mit filter-repo oder BFG bereinigen 🟠 Schnell
3 Force-Push durchführen 🟠 Schnell
4 GitHub-Support kontaktieren 🟡 Zeitnah
5 Team/Mitwirkende informieren 🟡 Zeitnah

Wie du das in Zukunft verhinderst

Damit dir das nicht wieder passiert, solltest du einige Vorkehrungen treffen:

  1. .gitignore richtig konfigurieren – sensible Dateien wie .env, config/secrets.php oder credentials.json sollten niemals getrackt werden:

    # Umgebungsvariablen und Secrets
.env
.env.local
*.pem
*.key
config/secrets.php

  2. Umgebungsvariablen nutzen – speichere Passwörter und API-Keys in Umgebungsvariablen statt direkt im Code:

    // ❌ Schlecht
$password = "geheim123";

// ✅ Gut
$password = getenv('DB_PASSWORD');

  3. Pre-Commit-Hooks einrichten – Tools wie git-secrets oder pre-commit können automatisch nach Secrets suchen, bevor du commitest

  4. GitHub Secret Scanning aktivieren – GitHub scannt öffentliche Repositories automatisch nach bekannten Secret-Formaten und warnt dich

Fazit

Das versehentliche Pushen von Passwörtern ist ein häufiger und potenziell schwerwiegender Fehler. Die wichtigste Erkenntnis ist: Einfaches Löschen reicht nicht, weil Git die komplette Historie aufbewahrt. Deine erste Reaktion muss immer sein, das kompromittierte Geheimnis sofort ungültig zu machen – erst danach kümmere dich um die Bereinigung der Historie.

Kapitel 9: Praktischer Workflow für Einsteiger

Einleitung: Du kennst jetzt alle wichtigen Git-Befehle und -Konzepte – aber wie setzt du das im Alltag zusammen? Ein guter Workflow gibt dir Struktur und verhindert Chaos. Als Einzelentwickler brauchst du keinen komplexen Prozess, aber ein paar bewährte Praktiken helfen enorm: regelmäßig committen, aussagekräftige Nachrichten schreiben, Features in eigenen Branches entwickeln, und den Main-Branch immer funktionsfähig halten. Dieses Kapitel zeigt dir einen praktikablen Workflow, den du sofort anwenden kannst. Außerdem lernst du GitHub-Features wie Issues kennen, die dir helfen, auch als Solo-Entwickler den Überblick über Aufgaben und Ideen zu behalten.

Kapitel 9: Praktischer Workflow für Einsteiger

Ein einfacher Git-Workflow für Einzelentwickler 🛠️

Als Einzelentwickler brauchst du keinen komplizierten Workflow mit Pull Requests, Code Reviews oder Release-Branches. Trotzdem lohnt es sich, ein paar klare Gewohnheiten zu etablieren – sie halten dein Projekt übersichtlich, schützen dich vor Datenverlust und machen es leichter, Fehler zu finden oder rückgängig zu machen.

Der empfohlene Workflow im Überblick

flowchart TD
    START["🌅 Arbeitstag beginnen"] --> PULL["git pull\nAktuellen Stand holen"]
    PULL --> BRANCH{"Neues Feature\noder Experiment?"}
    BRANCH -->|Ja| CREATE["Neuen Branch erstellen\nz.B. feature/kontaktformular"]
    BRANCH -->|Nein| WORK["Direkt auf main arbeiten\nbei kleinen Aenderungen"]
    CREATE --> WORK2["Im Feature-Branch arbeiten"]
    WORK --> COMMIT["Regelmaessig committen\nbei logischen Einheiten"]
    WORK2 --> COMMIT
    COMMIT --> MORE{"Weitere\nAenderungen?"}
    MORE -->|Ja| COMMIT
    MORE -->|Nein| MERGE["Feature-Branch mergen\nfalls vorhanden"]
    MERGE --> PUSH["git push\nAendeurngen sichern"]
    PUSH --> END["🌙 Feierabend"]

Dein typischer Arbeitstag mit Git

1. Arbeitsbeginn: Aktuellen Stand holen 🌅

Bevor du mit der Arbeit beginnst, solltest du sicherstellen, dass dein lokales Repository auf dem neuesten Stand ist – besonders wenn du an mehreren Geräten arbeitest oder gelegentlich direkt auf GitHub kleine Änderungen machst.

git pull

In PhpStorm geht das über Git → Pull oder mit dem blauen Pfeil-nach-unten-Button in der Toolbar. Dieser kurze Schritt verhindert, dass du später mit Push-Konflikten kämpfen musst.

2. Entscheiden: Branch oder nicht? 🌿

Hier kommt die wichtigste Frage des Tages:

Situation Empfehlung
Kleiner Bugfix, Tippfehler, CSS-Anpassung Direkt auf main arbeiten
Neues Feature, größere Änderung, Experiment Eigenen Branch erstellen
Du bist unsicher, ob die Änderung funktioniert Eigenen Branch erstellen

Faustregel: Wenn du dir vorstellst, dass du die Änderung möglicherweise komplett verwerfen willst, gehört sie in einen eigenen Branch.

Einen neuen Branch erstellst du in PhpStorm über die Branch-Anzeige unten rechts → New Branch. Benenne ihn sprechend, z. B.:

3. Arbeiten und Committen: Die goldene Regel ✍️

Committe früh und oft – aber nicht wahllos. Ein Commit sollte eine logische Einheit darstellen, also eine abgeschlossene kleine Änderung, die für sich allein Sinn ergibt.

Gute Zeitpunkte für einen Commit:

Schlechte Zeitpunkte für einen Commit:

💡 Tipp: Lieber fünf kleine Commits mit klaren Nachrichten als ein riesiger Commit mit „diverse Änderungen".

Beispiel für einen typischen Vormittag:

09:15  Commit: "Kontaktformular HTML-Struktur erstellt"
09:45  Commit: "Validierung für E-Mail-Feld hinzugefügt"
10:30  Commit: "Formular-Styling angepasst"
11:00  Commit: "E-Mail-Versand implementiert"

4. Feature fertig: Mergen 🔀

Wenn du in einem Feature-Branch gearbeitet hast und zufrieden bist:

  1. Wechsle zurück zu main (in PhpStorm: Branch-Anzeige → main → Checkout)
  2. Merge den Feature-Branch (in PhpStorm: Branch-Anzeige → deinen Feature-Branch → Merge into Current)
  3. Lösche den Feature-Branch (optional, aber hält die Liste sauber)

Bei einem Einzelentwickler-Projekt entstehen hier selten Konflikte, weil niemand anders parallel an main arbeitet.

5. Arbeitsende: Pushen und sichern 🌙

Am Ende jedes Arbeitstages solltest du pushen – egal ob du „fertig" bist oder nicht. Der Push ist dein Backup in der Cloud. Wenn dein Laptop morgen kaputtgeht, ist deine Arbeit sicher.

git push

Oder in PhpStorm: Git → Push bzw. der grüne Pfeil-nach-oben-Button.

⚠️ Wichtig: Pushe nur Branches, mit denen du aktiv arbeitest. Unfertige Feature-Branches kannst du auch pushen – sie liegen dann sicher auf GitHub, ohne main zu beeinflussen.

Zusammenfassung: Die wichtigsten Gewohnheiten

Wann Was Warum
Arbeitsbeginn git pull Aktuellen Stand holen, Konflikte vermeiden
Vor größeren Änderungen Neuen Branch erstellen Saubere Trennung, einfaches Verwerfen möglich
Nach jeder logischen Einheit Committen mit guter Nachricht Nachvollziehbare Historie, einfaches Zurückrollen
Feature abgeschlossen Branch mergen Änderungen in main integrieren
Arbeitsende git push Backup in der Cloud, Zugriff von überall

Zusätzliche Tipps für den Alltag 💡

Commit-Nachrichten: Schreibe so, dass du in drei Monaten noch verstehst, was du getan hast. „Login gefixt" ist schlecht, „Redirect-Schleife beim Login behoben, wenn Session abgelaufen" ist gut.

Nicht committen: Halte dich an deine .gitignore – Dependencies (vendor/, node_modules/), IDE-Einstellungen und sensible Daten gehören nicht ins Repository.

Regelmäßigkeit schlägt Perfektion: Es ist besser, jeden Tag etwas zu pushen, als alle zwei Wochen einen perfekten Mega-Commit zu machen. Git ist ein Werkzeug für deinen Alltag, nicht für besondere Anlässe.

Kapitel 9: Praktischer Workflow für Einsteiger

Der Feature-Branch-Workflow – sauber entwickeln in PhpStorm 🌿

Direkt auf dem main-Branch zu arbeiten ist keine gute Idee – selbst wenn du alleine arbeitest. Der sogenannte Feature-Branch-Workflow ist eine einfache, aber wirkungsvolle Methode, um dein Projekt sauber und sicher zu halten. Hier erfährst du, warum das so ist und wie du diesen Workflow in PhpStorm praktisch umsetzt.

Warum nicht direkt auf main arbeiten?

Der main-Branch (früher oft master genannt) sollte immer den stabilen, funktionierenden Zustand deines Projekts repräsentieren. Wenn du direkt darauf arbeitest, riskierst du mehrere Probleme:

Der Feature-Branch-Workflow löst all diese Probleme elegant.

Das Prinzip des Feature-Branch-Workflows

Die Idee ist simpel:

Für jedes neue Feature, jeden Bugfix oder jedes Experiment erstellst du einen eigenen Branch. Erst wenn die Arbeit fertig und getestet ist, führst du den Branch in main zusammen.

flowchart TD
    MAIN["main-Branch\nImmer stabil und funktionsfaehig"] 
    FEATURE1["feature/login-formular\nNeues Feature entwickeln"]
    FEATURE2["bugfix/navbar-fehler\nBug beheben"]
    
    MAIN -->|"Branch erstellen"| FEATURE1
    MAIN -->|"Branch erstellen"| FEATURE2
    FEATURE1 -->|"Merge nach Fertigstellung"| MAIN
    FEATURE2 -->|"Merge nach Fertigstellung"| MAIN
    
    style MAIN fill:#c8e6c9,color:#000000
    style FEATURE1 fill:#bbdefb,color:#000000
    style FEATURE2 fill:#ffe0b2,color:#000000

Dadurch bleibt main immer in einem Zustand, den du jederzeit deployen oder jemandem zeigen könntest.

Der Workflow Schritt für Schritt

1. Vor dem Start: Aktuellen Stand holen

Bevor du einen neuen Branch erstellst, solltest du sicherstellen, dass dein lokaler main-Branch auf dem neuesten Stand ist. In PhpStorm:

  1. Wechsle zum main-Branch (falls nicht schon dort) – klicke dafür auf den Branch-Namen unten rechts und wähle main.
  2. Führe einen Pull durch: Git → Pull oder Ctrl+T (Windows) / Cmd+T (Mac).

2. Neuen Feature-Branch erstellen

Jetzt erstellst du einen Branch für dein Vorhaben:

  1. Klicke auf den Branch-Namen unten rechts in PhpStorm.
  2. Wähle New Branch aus dem Popup-Menü.
  3. Gib einen aussagekräftigen Namen ein, zum Beispiel:
    • feature/kontaktformular – für ein neues Feature
    • bugfix/login-fehler – für eine Fehlerbehebung
    • experiment/neues-design – für etwas, das du ausprobieren möchtest
  4. Stelle sicher, dass Checkout branch aktiviert ist (damit du direkt auf den neuen Branch wechselst).
  5. Klicke auf Create.

💡 Tipp zur Benennung: Verwende Prefixe wie feature/, bugfix/ oder experiment/, gefolgt von einer kurzen Beschreibung. Das macht deine Branch-Liste übersichtlich.

3. Arbeiten und regelmäßig committen

Jetzt arbeitest du ganz normal auf deinem neuen Branch:

Das Schöne daran: Alles, was du hier commitest, landet nur in diesem Branch. Dein main bleibt davon unberührt.

4. Feature fertig? Zurück zu main wechseln

Wenn du mit deiner Arbeit fertig bist und alles getestet hast:

  1. Wechsle zurück zum main-Branch – klicke auf den Branch-Namen unten rechts und wähle main → Checkout.
  2. Optional, aber empfohlen: Hole dir den neuesten Stand mit Pull, falls sich zwischenzeitlich etwas geändert hat.

5. Feature-Branch in main mergen

Jetzt führst du deinen Feature-Branch in main zusammen:

  1. Klicke wieder auf den Branch-Namen unten rechts.
  2. Finde deinen Feature-Branch in der Liste (z. B. feature/kontaktformular).
  3. Klicke darauf und wähle Merge into Current (oder „In aktuellen Branch mergen").
  4. PhpStorm führt den Merge durch. Wenn es keine Konflikte gibt, ist alles sofort erledigt.
  5. Bei einem Merge-Konflikt öffnet PhpStorm automatisch das Konflikt-Tool – löse die Konflikte wie gewohnt.

6. Änderungen pushen

Nach dem Merge solltest du deinen aktualisierten main-Branch auf GitHub pushen:

7. Feature-Branch aufräumen (optional, aber empfohlen)

Der Feature-Branch hat seinen Zweck erfüllt. Du kannst ihn jetzt löschen, um deine Branch-Liste sauber zu halten:

  1. Klicke auf den Branch-Namen unten rechts.
  2. Finde den gemergten Feature-Branch.
  3. Klicke darauf und wähle Delete – PhpStorm fragt dich, ob du ihn auch remote löschen möchtest (falls du ihn gepusht hattest).

Der komplette Ablauf visualisiert

flowchart TD
    A["1. Auf main wechseln\nund Pull durchfuehren"] --> B["2. Neuen Branch erstellen\nz.B. feature/warenkorb"]
    B --> C["3. Entwickeln und\nregelmaessig committen"]
    C --> D{"4. Feature fertig\nund getestet?"}
    D -->|"Nein"| C
    D -->|"Ja"| E["5. Zu main wechseln\nund Pull durchfuehren"]
    E --> F["6. Feature-Branch\nin main mergen"]
    F --> G["7. main auf\nGitHub pushen"]
    G --> H["8. Feature-Branch\nloeschen"]
    H --> I["Fertig!"]
    
    style A fill:#e3f2fd,color:#000000
    style B fill:#e3f2fd,color:#000000
    style C fill:#fff3e0,color:#000000
    style D fill:#fce4ec,color:#000000
    style E fill:#e3f2fd,color:#000000
    style F fill:#c8e6c9,color:#000000
    style G fill:#c8e6c9,color:#000000
    style H fill:#f3e5f5,color:#000000
    style I fill:#c8e6c9,color:#000000

Praktisches Beispiel: Ein Kontaktformular entwickeln

Angenommen, du möchtest ein Kontaktformular zu deinem PHP-Projekt hinzufügen:

  1. Pull auf main – sicherstellen, dass du aktuell bist.
  2. Branch erstellen: feature/kontaktformular
  3. Arbeiten:
    • Commit 1: „HTML-Struktur für Kontaktformular erstellt"
    • Commit 2: „CSS-Styling hinzugefügt"
    • Commit 3: „PHP-Verarbeitung implementiert"
    • Commit 4: „E-Mail-Validierung ergänzt"
  4. Testen – alles funktioniert wie gewünscht.
  5. Zu main wechseln und Pull durchführen.
  6. Merge von feature/kontaktformular in main.
  7. Push des aktualisierten main auf GitHub.
  8. Branch löschen: feature/kontaktformular wird nicht mehr benötigt.

Falls du mitten in der Arbeit einen dringenden Bug im Live-System fixen müsstest, wäre das kein Problem: Du könntest einfach zu main wechseln, einen neuen bugfix/-Branch erstellen, den Fehler beheben, mergen und dann zu deinem Kontaktformular-Branch zurückkehren.

Zusammenfassung: Die goldenen Regeln

Regel Warum?
main ist immer stabil Du kannst jederzeit deployen oder demonstrieren
Ein Branch pro Aufgabe Klare Trennung, einfaches Verwerfen
Aussagekräftige Branch-Namen Du findest dich auch in einer Woche noch zurecht
Regelmäßig committen Kleine Schritte sind leichter nachzuvollziehen
Nach dem Merge aufräumen Keine Verwirrung durch alte Branches

Dieser Workflow mag anfangs wie ein Umweg erscheinen, aber nach kurzer Zeit wird er zur Gewohnheit – und du wirst dich fragen, wie du jemals ohne Branches gearbeitet hast. 🚀

Kapitel 9: Praktischer Workflow für Einsteiger

Nützliche GitHub-Features für Einzelentwickler 🎯

Auch wenn du alleine arbeitest, bietet GitHub eine Reihe von Features, die dir helfen, den Überblick zu behalten, Ideen zu sammeln und deine Projekte professionell zu organisieren. Du musst nicht alles nutzen – aber die folgenden Werkzeuge sind auch für Solo-Projekte überraschend praktisch.

Issues – dein persönliches Aufgaben- und Ideenboard 📋

Issues sind weit mehr als nur ein Bug-Tracker für Teams. Als Einzelentwickler kannst du sie nutzen als:

Praktische Tipps für Issues

  1. Labels verwenden

    GitHub erlaubt dir, Issues mit farbigen Labels zu versehen. Erstelle dir ein paar einfache Kategorien wie:

    • bug (rot) – Fehler, die behoben werden müssen
    • feature (grün) – Neue Funktionen
    • idee (blau) – Vage Konzepte für später
    • dringend (orange) – Priorität

  2. Milestones setzen

    Wenn du auf eine bestimmte Version oder einen Veröffentlichungstermin hinarbeitest, kannst du einen Milestone erstellen (z. B. „Version 1.0" oder „Launch März") und Issues diesem zuordnen. So siehst du auf einen Blick, wie viel noch zu tun ist.

  3. Issue-Templates anlegen

    Wenn du merkst, dass du bestimmte Informationen immer wieder brauchst (z. B. bei Bugs: „Was sollte passieren? Was passiert stattdessen?"), kannst du dir im Repository unter .github/ISSUE_TEMPLATE/ Vorlagen anlegen.

💡 Tipp: Du kannst Issues direkt in Commit-Nachrichten referenzieren. Schreibst du z. B. Fix: Login-Fehler behoben, closes #12, wird Issue #12 automatisch geschlossen, sobald der Commit im main-Branch landet.

Projects – visuelles Projektmanagement 📊

GitHub Projects ist ein Kanban-ähnliches Board, das dir hilft, deine Issues und Aufgaben visuell zu organisieren. Selbst als Einzelentwickler kann das enorm nützlich sein:

Wie du Projects sinnvoll nutzt

Ein typisches Board für ein Solo-Projekt könnte drei Spalten haben:

flowchart LR
    A["📥 Backlog\nAlles, was irgendwann gemacht werden soll"] --> B["🔨 In Arbeit\nWoran du gerade aktiv arbeitest"]
    B --> C["✅ Erledigt\nAbgeschlossene Aufgaben"]

Der Vorteil gegenüber einer einfachen Issue-Liste:

Einrichtung in GitHub

  1. Gehe in deinem Repository auf den Reiter Projects
  2. Klicke auf New project
  3. Wähle ein Template (z. B. „Board") oder starte leer
  4. Füge Spalten hinzu und ziehe bestehende Issues hinein

💡 Tipp: GitHub hat Projects kürzlich überarbeitet (die neue Version heißt „Projects (beta)" oder manchmal einfach „Projects v2"). Diese neue Variante bietet mehr Flexibilität, z. B. eigene Felder, Filter und verschiedene Ansichten.

Releases – Versionen deiner Software veröffentlichen 📦

Releases sind ein Weg, um stabile Versionen deines Projekts zu markieren und zum Download anzubieten. Das klingt vielleicht nach etwas, das nur große Open-Source-Projekte brauchen – aber auch als Einzelentwickler profitierst du davon:

Warum Releases sinnvoll sind

Einen Release erstellen

  1. Gehe im Repository auf Releases (rechte Seite oder unter „Code")
  2. Klicke auf Create a new release
  3. Tag-Version wählen: Erstelle einen neuen Tag (z. B. v1.0.0 oder v0.1.0-beta) oder wähle einen bestehenden Tag aus. Tags sind im Grunde Lesezeichen auf bestimmte Commits.
  4. Titel und Beschreibung: Gib dem Release einen aussagekräftigen Namen und beschreibe, was enthalten ist
  5. Optional: Dateien anhängen – falls du z. B. ein fertiges ZIP mit deiner Anwendung bereitstellen willst

Versionierung verstehen

Eine bewährte Konvention ist Semantic Versioning (SemVer):

Format Bedeutung
v1.0.0 Major.Minor.Patch
Major Große, nicht abwärtskompatible Änderungen
Minor Neue Features, abwärtskompatibel
Patch Bugfixes, kleine Korrekturen

Für ein Solo-Projekt musst du das nicht streng befolgen, aber eine konsistente Nummerierung hilft trotzdem beim Überblick.

Weitere nützliche Features im Überblick

Wiki – Dokumentation für dein Projekt 📚

Das Wiki ist ein einfacher Ort, um längere Dokumentation zu speichern:

Für kleine Projekte reicht oft eine gute README.md, aber wenn dein Projekt wächst, ist das Wiki ein praktischer Ort für alles, was nicht in die README passt.

GitHub Actions – Automatisierung ⚙️

Actions sind GitHubs Werkzeug für Automatisierung (CI/CD). Auch als Einzelentwickler kannst du damit:

Das ist etwas fortgeschrittener, aber selbst ein einfacher Workflow, der bei jedem Push deine Tests ausführt, kann viel Ärger sparen.

Discussions – Gedanken sortieren 💬

Falls du dein Repository irgendwann öffentlich machst oder einfach einen Ort für „größere Überlegungen" brauchst, die nicht direkt eine Aufgabe sind, bieten Discussions einen Rahmen dafür. Für rein private Solo-Projekte ist das meist überflüssig.

Ein einfacher Workflow für Solo-Projekte

Hier ist ein Vorschlag, wie du diese Features kombinieren kannst, ohne dich in Overhead zu verlieren:

flowchart TD
    IDEE["💡 Neue Idee oder Bug entdeckt"] --> ISSUE["📋 Issue erstellen\nmit passendem Label"]
    ISSUE --> BACKLOG["📥 Issue ins Project-Board\nSpalte: Backlog"]
    BACKLOG --> START["🔨 Arbeit beginnen\nIssue in: In Arbeit"]
    START --> BRANCH["🌿 Feature-Branch erstellen\nz.B. feature/issue-15"]
    BRANCH --> COMMIT["💾 Commits machen\nmit Issue-Referenz"]
    COMMIT --> MERGE["🔀 Branch mergen\nIssue wird geschlossen"]
    MERGE --> DONE["✅ Issue in: Erledigt"]
    DONE --> RELEASE{Genug für\nneue Version?}
    RELEASE -->|Ja| TAG["📦 Release erstellen\nmit Changelog"]
    RELEASE -->|Nein| IDEE
    TAG --> IDEE

Fazit: Weniger ist oft mehr 🎯

Du musst nicht alle Features nutzen. Für den Anfang empfehle ich:

  1. Issues für Aufgaben und Bugs – das ist der größte Gewinn für die Organisation
  2. Releases für wichtige Meilensteine – gibt dir Orientierung und Sicherheit
  3. Projects optional, wenn du merkst, dass du den Überblick verlierst

Mit diesen Werkzeugen entwickelst du auch alleine strukturierter und professioneller – und falls dein Projekt irgendwann wächst oder du es öffentlich machst, hast du bereits eine solide Grundlage.

Kapitel 10: PhpStorm Git-Funktionen meistern 🛠️

Einleitung: PhpStorm ist nicht nur eine großartige IDE für PHP-Entwicklung, sondern hat auch eine der besten Git-Integrationen auf dem Markt. Viele Entwickler nutzen jedoch nur einen Bruchteil der verfügbaren Funktionen. In diesem abschließenden Kapitel tauchst du tiefer in die Möglichkeiten ein: Du lernst, die Diff-Ansicht effektiv zu nutzen, um Änderungen zu visualisieren, einzelne Code-Zeilen statt ganzer Dateien zu committen (sogenanntes „Partial Commit"), und die Historie deines Projekts detailliert zu analysieren. Mit den richtigen Tastenkombinationen wird Git in PhpStorm zum natürlichen Teil deines Workflows, der dich nicht aufhält, sondern unterstützt.

Kapitel 10: PhpStorm Git-Funktionen meistern 🛠️

Git-Funktionen in PhpStorm – Der komplette Überblick 🧭

PhpStorm hat eine der umfangreichsten Git-Integrationen aller IDEs. Fast alles, was du sonst im Terminal machen würdest, kannst du direkt in der grafischen Oberfläche erledigen – oft sogar komfortabler. Hier bekommst du einen strukturierten Überblick über alle wichtigen Git-Funktionen und wo du sie findest.

Die wichtigsten Bereiche der Git-Oberfläche

PhpStorm organisiert seine Git-Funktionen an mehreren Stellen. Sobald du diese kennst, findest du dich schnell zurecht:

flowchart TB
    subgraph UI["PhpStorm Git-Oberfläche"]
        MENU["📋 Hauptmenü\nGit-Menü oben"]
        TOOLBAR["🔧 Toolbar\nSchnellzugriff-Icons"]
        STATUSBAR["📍 Statusleiste\nBranch-Anzeige unten rechts"]
        TOOLWINDOW["🪟 Tool-Fenster\nGit-Tab unten"]
        CONTEXT["🖱️ Kontextmenü\nRechtsklick auf Dateien"]
        GUTTER["📝 Editor-Gutter\nLinke Seite im Editor"]
    end
    
    MENU --> TOOLWINDOW
    TOOLBAR --> TOOLWINDOW
    STATUSBAR --> TOOLWINDOW

Das Git-Hauptmenü

Das Git-Menü in der oberen Menüleiste ist dein zentraler Anlaufpunkt für alle Git-Operationen. Hier findest du wirklich alles – von den Basics bis zu fortgeschrittenen Funktionen.

Menüpunkt Funktion Tastenkürzel
Commit Öffnet das Commit-Fenster Strg + K (Win/Linux) / Cmd + K (Mac)
Push Lokale Commits auf Remote hochladen Strg + Shift + K / Cmd + Shift + K
Pull Änderungen vom Remote holen und mergen –
Fetch Nur Remote-Infos holen (ohne Merge) –
Merge Branches zusammenführen –
Rebase Branch auf anderen Branch umbasieren –
Branches Branch-Verwaltung öffnen –
Show Git Log Commit-Historie anzeigen –
Rollback Änderungen verwerfen –
Stash Changes Änderungen temporär zwischenspeichern –
Unstash Changes Zwischengespeicherte Änderungen wiederherstellen –

💡 Tipp: Die meisten Menüpunkte haben Untermenüs mit weiteren Optionen. Es lohnt sich, diese einmal durchzugehen!

Die Statusleiste – dein ständiger Begleiter

Am unteren rechten Rand von PhpStorm findest du die Statusleiste mit der Branch-Anzeige. Diese kleine Anzeige ist überraschend mächtig:

flowchart LR
    STATUS["📍 Statusleiste\nmain"] -->|Klick| POPUP["Branch-Popup"]
    POPUP --> LOCAL["🌿 Lokale Branches"]
    POPUP --> REMOTE["☁️ Remote Branches"]
    POPUP --> NEW["➕ New Branch"]
    POPUP --> CHECKOUT["🔄 Checkout"]

Das Git-Tool-Fenster

Das Git-Tool-Fenster am unteren Rand (Reiter „Git") ist das Herzstück für die Arbeit mit der Versionshistorie. Es hat mehrere Tabs:

Log-Tab 📜

Hier siehst du die gesamte Commit-Historie deines Projekts in einer grafischen Darstellung:

Local Changes / Changes-Tab 📝

Zeigt alle aktuell geänderten Dateien – also alles, was seit dem letzten Commit verändert wurde:

Console-Tab 💻

Zeigt die tatsächlichen Git-Befehle, die PhpStorm im Hintergrund ausführt. Sehr nützlich, um zu verstehen, was passiert – oder um Fehlermeldungen zu analysieren.

Kontextmenü – Git per Rechtsklick

Wenn du im Projektbaum oder im Editor mit der rechten Maustaste auf eine Datei klickst, findest du unter Git zahlreiche dateispezifische Optionen:

Funktion Was sie tut
Add Datei zur Staging Area hinzufügen
Commit File Nur diese Datei committen
Show History Zeigt alle Commits, die diese Datei betreffen
Show Diff Vergleicht aktuelle Version mit letztem Commit
Annotate with Git Blame Zeigt zeilenweise, wer wann was geändert hat
Rollback Änderungen an dieser Datei verwerfen
Compare with Branch Datei mit Version aus anderem Branch vergleichen

Der Editor-Gutter – Änderungen auf einen Blick

Am linken Rand des Editors (neben den Zeilennummern) zeigt PhpStorm farbige Markierungen für Änderungen:

Farbe Bedeutung
🟢 Grün Neue Zeilen (hinzugefügt)
🔵 Blau Geänderte Zeilen
🔺 Dreieck/Pfeil Gelöschte Zeilen (an dieser Stelle wurde etwas entfernt)

Klickst du auf diese Markierungen, öffnet sich ein kleines Popup mit mehreren Optionen:

💡 Diese Funktion ist extrem praktisch, um einzelne Änderungen chirurgisch rückgängig zu machen, ohne gleich die ganze Datei zurückzusetzen.

Die Toolbar – Schnellzugriff für häufige Aktionen

In der oberen Toolbar findest du Icons für die häufigsten Git-Operationen. Je nach PhpStorm-Version und Konfiguration können diese leicht variieren:

Das Commit-Fenster im Detail

Das Commit-Fenster (Strg + K / Cmd + K) verdient besondere Aufmerksamkeit, weil du es am häufigsten nutzen wirst:

flowchart TB
    subgraph COMMIT["Commit-Fenster"]
        FILES["📁 Dateiliste\nmit Checkboxen"]
        DIFF["🔍 Diff-Vorschau\nrechts daneben"]
        MESSAGE["✍️ Commit-Nachricht\nTextfeld unten"]
        OPTIONS["⚙️ Optionen\nAmend, Sign-off, etc."]
        BUTTONS["🔘 Buttons\nCommit / Commit and Push"]
    end
    
    FILES --> DIFF
    MESSAGE --> BUTTONS
    OPTIONS --> BUTTONS

Wichtige Funktionen im Commit-Fenster:

Die am häufigsten genutzten Funktionen 🏆

Im Alltag wirst du einen kleinen Teil der Git-Funktionen sehr oft nutzen, während andere nur in speziellen Situationen gebraucht werden:

Täglich mehrfach genutzt

  1. Commit (Strg + K / Cmd + K)
    Du wirst ständig Commits machen – das ist das Herzstück von Git.

  2. Push (Strg + Shift + K / Cmd + Shift + K)
    Nach dem Committen willst du deine Arbeit sichern.

  3. Pull / Update Project
    Zu Beginn jeder Arbeitssession holst du dir den aktuellen Stand.

  4. Branch wechseln (Statusleiste unten rechts)
    Wenn du mit Feature-Branches arbeitest, wechselst du regelmäßig.

  5. Diff anzeigen (Editor-Gutter oder Doppelklick im Commit-Fenster)
    Du willst vor dem Commit sehen, was du geändert hast.

Regelmäßig genutzt

  1. Neuen Branch erstellen (Statusleiste → New Branch)
    Für jedes neue Feature oder Experiment.

  2. Merge (Git-Menü oder Branch-Popup)
    Wenn ein Feature fertig ist, mergst du es zurück.

  3. Git Log (Git-Tool-Fenster)
    Um die Historie zu durchsuchen oder alte Commits zu finden.

  4. Rollback (Editor-Gutter oder Kontextmenü)
    Um Änderungen zu verwerfen, die du doch nicht willst.

  5. Show History (Kontextmenü auf einer Datei)
    Um zu sehen, wie sich eine bestimmte Datei entwickelt hat.

Gelegentlich genutzt

  1. Amend Commit (Checkbox im Commit-Fenster)
    Wenn du den letzten Commit korrigieren musst.

  2. Git Blame / Annotate (Kontextmenü)
    Um herauszufinden, wer eine bestimmte Zeile geschrieben hat.

  3. Stash / Unstash (Git-Menü)
    Um Änderungen temporär beiseitezulegen.

  4. Cherry-Pick (Rechtsklick auf Commit im Log)
    Um einzelne Commits in einen anderen Branch zu übernehmen.

  5. Revert Commit (Rechtsklick auf Commit im Log)
    Um einen Commit rückgängig zu machen (mit neuem Commit).

Übersicht: Wo finde ich was?

Was will ich tun? Wo finde ich es?
Committen Strg + K oder Git-Menü → Commit
Pushen Strg + Shift + K oder Git-Menü → Push
Pullen Git-Menü → Pull oder Toolbar-Icon
Branch wechseln Statusleiste unten rechts
Neuen Branch erstellen Statusleiste → New Branch
Branches mergen Git-Menü → Merge oder Branch-Popup → Merge into Current
Historie ansehen Git-Tool-Fenster (unten) → Log-Tab
Datei-Historie ansehen Rechtsklick auf Datei → Git → Show History
Änderungen vergleichen Editor-Gutter oder Rechtsklick → Git → Show Diff
Änderungen verwerfen Editor-Gutter-Klick → Rollback oder Rechtsklick → Git → Rollback
Merge-Konflikte lösen Automatisches Popup oder Git-Menü → Resolve Conflicts
Letzten Commit ändern Im Commit-Fenster: Checkbox „Amend commit"

Mein Tipp für den Einstieg 💡

Konzentriere dich am Anfang auf diese fünf Kernfunktionen:

  1. Commit (Strg + K)
  2. Push (Strg + Shift + K)
  3. Pull (Git-Menü oder Toolbar)
  4. Branch wechseln (Statusleiste)
  5. Git Log ansehen (Tool-Fenster unten)

Wenn du diese fünf beherrschst, deckst du 90% deines Git-Alltags ab. Die restlichen Funktionen lernst du dann nach und nach kennen, wenn du sie brauchst – und du weißt jetzt, wo du sie findest! 🚀

Kapitel 10: PhpStorm Git-Funktionen meistern 🛠️

Die Diff-Ansicht in PhpStorm – Änderungen verstehen und gezielt committen 🔍

Wenn du an deinem Code arbeitest, möchtest du oft wissen: Was genau habe ich eigentlich seit dem letzten Commit geändert? Und manchmal möchtest du nicht alle Änderungen auf einmal committen, sondern nur bestimmte Teile. PhpStorm bietet dir dafür eine leistungsstarke Diff-Ansicht und die Möglichkeit, Änderungen auf Zeilen-Ebene auszuwählen – sogenannte partielle Commits oder Chunk-basiertes Staging.

Änderungen seit dem letzten Commit anzeigen

Es gibt mehrere Wege, um zu sehen, was sich in deinen Dateien geändert hat:

Weg 1: Über das Commit-Fenster

  1. Öffne das Commit-Fenster mit Strg + K (Windows/Linux) oder Cmd + K (macOS) – alternativ über Git → Commit.
  2. Im linken Bereich siehst du alle Dateien, die seit dem letzten Commit verändert wurden. Sie sind farblich markiert:
    • Blau: Geänderte Dateien (modified)
    • Grün: Neue Dateien (untracked/added)
    • Rot/Grau: Gelöschte Dateien
  3. Doppelklicke auf eine Datei, um die Diff-Ansicht zu öffnen.

Weg 2: Direkt im Editor

Wenn du eine Datei geöffnet hast, zeigt PhpStorm dir Änderungen direkt im Randbereich (Gutter) an:

Klickst du auf eine dieser Markierungen, öffnet sich ein kleines Popup, das dir den vorherigen Zustand zeigt und dir erlaubt, die Änderung direkt rückgängig zu machen.

Weg 3: Über das Kontextmenü

  1. Rechtsklicke auf eine Datei im Projektbaum oder im Commit-Fenster.
  2. Wähle Git → Show Diff (oder einfach Compare with… → Last Commit).

Die Diff-Ansicht verstehen

Wenn du die Diff-Ansicht öffnest, siehst du standardmäßig eine Side-by-Side-Darstellung:

┌─────────────────────────────┬─────────────────────────────┐
│     Alter Zustand           │      Neuer Zustand          │
│     (letzter Commit)        │      (deine Änderungen)     │
├─────────────────────────────┼─────────────────────────────┤
│  function login() {         │  function login() {         │
│      // alte Logik          │      // verbesserte Logik   │
│      return false;          │      $user = checkUser();   │
│  }                          │      return $user !== null; │
│                             │  }                          │
└─────────────────────────────┴─────────────────────────────┘

Die wichtigsten Elemente:

💡 Tipp: Du kannst die Darstellung umschalten – über das Zahnrad-Icon in der Diff-Ansicht kannst du zwischen Side-by-Side und Unified View (alles untereinander) wechseln.

Einzelne Änderungen zum Commit auswählen – partielle Commits

Jetzt kommt das wirklich Mächtige: Du musst nicht die gesamte Datei committen. PhpStorm erlaubt dir, einzelne Chunks (zusammenhängende Änderungsblöcke) oder sogar einzelne Zeilen auszuwählen.

Warum ist das nützlich?

Stell dir vor, du hast in einer Datei zwei verschiedene Dinge gemacht:

Das sind logisch zwei verschiedene Änderungen, die eigentlich in zwei verschiedene Commits gehören (mit jeweils aussagekräftiger Commit-Nachricht). Mit partiellen Commits kannst du genau das tun.

So funktioniert es in PhpStorm

  1. Öffne das Commit-Fenster (Strg + K / Cmd + K).

  2. Klicke auf das Zahnrad-Icon (⚙️) im Commit-Fenster und aktiviere die Option „Include into commit" oder ähnlich, falls nicht schon aktiv.

  3. Doppelklicke auf die Datei, um die Diff-Ansicht zu öffnen.

  4. In der Diff-Ansicht siehst du nun Checkboxen neben jedem Änderungsblock (Chunk):

    ☑️ Chunk 1: Login-Logik geändert (Zeile 15-22)
☐ Chunk 2: Kommentar aktualisiert (Zeile 45-46)

  5. Aktiviere oder deaktiviere die Checkboxen, um festzulegen, welche Chunks in diesen Commit aufgenommen werden sollen.

  6. Für noch feinere Kontrolle: Manche Versionen von PhpStorm erlauben es, per Rechtsklick auf einen Chunk einzelne Zeilen auszuwählen.

  7. Schließe die Diff-Ansicht und schreibe deine Commit-Nachricht nur für die ausgewählten Änderungen.

  8. Nach dem Commit sind die nicht ausgewählten Änderungen immer noch da – du kannst sie im nächsten Commit mit einer anderen Nachricht speichern.

Visuelles Schema des Prozesses

flowchart TD
    A["📝 Datei mit mehreren Aenderungen"] --> B["Diff-Ansicht oeffnen"]
    B --> C{"Welche Chunks\ngehoeren zusammen?"}
    C --> D["Chunk 1 auswaehlen:\nLogin-Bugfix"]
    C --> E["Chunk 2 abwaehlen:\nKommentar-Update"]
    D --> F["Commit 1 erstellen:\nFix: Login-Validierung korrigiert"]
    F --> G["Chunk 2 ist noch da\nund wartet"]
    G --> H["Commit 2 erstellen:\nDocs: Kommentar aktualisiert"]

Praktisches Beispiel

Du hast folgende Änderungen in UserController.php:

Zeile Änderung Gehört zu
23-28 Passwort-Validierung hinzugefügt Feature: Sicherheit
45 Tippfehler in Variable korrigiert Fix: Typo
67-70 Neue Methode resetPassword() Feature: Sicherheit

Sinnvolle Vorgehensweise:

  1. Erster Commit: Zeilen 23-28 und 67-70 auswählen

    Commit-Nachricht: Feat: Passwort-Validierung und Reset-Funktion hinzugefügt

  2. Zweiter Commit: Zeile 45 auswählen

    Commit-Nachricht: Fix: Tippfehler in Variablenname korrigiert

So bleibt deine Git-Historie sauber und nachvollziehbar.

Nützliche Tastenkürzel in der Diff-Ansicht

Aktion Windows/Linux macOS
Diff-Ansicht öffnen Doppelklick auf Datei im Commit-Fenster Doppelklick auf Datei im Commit-Fenster
Zur nächsten Änderung springen F7 F7
Zur vorherigen Änderung springen Shift + F7 Shift + F7
Änderung übernehmen (von links nach rechts) Strg + Shift + → Cmd + Shift + →
Änderung rückgängig machen Klick auf den Rückgängig-Pfeil Klick auf den Rückgängig-Pfeil
Diff schließen Esc Esc

Zusammenfassung ✅

💡 Profi-Tipp: Gewöhne dir an, vor jedem Commit kurz die Diff-Ansicht zu öffnen und zu prüfen, ob wirklich alle Änderungen zusammengehören. Das dauert nur Sekunden, spart dir aber später viel Zeit beim Debugging oder wenn du eine bestimmte Änderung suchen musst.

Kapitel 10: PhpStorm Git-Funktionen meistern 🛠️

Git-Tastenkürzel in PhpStorm – schneller arbeiten mit Shortcuts ⌨️

Sobald du die grundlegenden Git-Funktionen in PhpStorm beherrschst, kannst du deinen Workflow erheblich beschleunigen, indem du die wichtigsten Aktionen per Tastenkürzel auslöst. Statt durch Menüs zu navigieren, erledigst du Commits, Branch-Wechsel und vieles mehr in Sekundenbruchteilen. Hier findest du die nützlichsten Shortcuts – organisiert nach Häufigkeit und Anwendungsbereich.

Die wichtigsten Shortcuts für den täglichen Git-Workflow

Diese Tastenkürzel wirst du vermutlich am häufigsten verwenden. Es lohnt sich, sie als Erstes zu verinnerlichen:

Aktion Windows/Linux macOS
Commit-Dialog öffnen Strg + K Cmd + K
Push durchführen Strg + Shift + K Cmd + Shift + K
Pull/Update durchführen Strg + T Cmd + T
VCS-Operationen-Popup Alt + ` (Backtick) Ctrl + V
Git-Log anzeigen Alt + 9 Cmd + 9

💡 Tipp: Das VCS-Operationen-Popup (Alt + `` bzw. Ctrl + V` auf macOS) ist besonders praktisch – es zeigt dir ein kontextbezogenes Menü mit allen relevanten Git-Aktionen für die aktuelle Datei oder das Projekt.

Branch-Management per Tastatur

Das Wechseln und Verwalten von Branches geht mit diesen Shortcuts deutlich schneller:

Aktion Windows/Linux macOS
Branches-Popup öffnen Strg + Shift + ` Cmd + Shift + `
Neuen Branch erstellen Über Branches-Popup → New Branch Über Branches-Popup → New Branch

Das Branches-Popup ist dein zentraler Anlaufpunkt für alles rund um Branches: Hier siehst du alle lokalen und Remote-Branches, kannst zwischen ihnen wechseln, neue erstellen, mergen oder löschen – alles ohne die Maus.

Änderungen vergleichen und navigieren

Wenn du verstehen möchtest, was sich geändert hat, helfen diese Shortcuts:

Aktion Windows/Linux macOS
Diff zur letzten Version anzeigen Strg + D (im Commit-Fenster) Cmd + D
Zur nächsten Änderung springen F7 (im Diff-Viewer) F7
Zur vorherigen Änderung springen Shift + F7 Shift + F7
Lokale Historie anzeigen Alt + Shift + H Cmd + Shift + H
Annotate (Blame) anzeigen Rechtsklick → Annotate with Git Blame –

Änderungen rückgängig machen

Für den Fall, dass du schnell einen Schritt zurück musst:

Aktion Windows/Linux macOS
Rollback (Änderungen verwerfen) Strg + Alt + Z Cmd + Option + Z
Letzte Aktion rückgängig Strg + Z Cmd + Z

Der Rollback-Shortcut ist besonders mächtig: Er setzt ausgewählte Dateien auf den letzten Commit-Stand zurück – praktisch, wenn du dich experimentell verrannt hast.

Nützliche allgemeine Shortcuts mit Git-Bezug

Diese Tastenkürzel sind nicht Git-spezifisch, helfen aber im Git-Workflow enorm:

Aktion Windows/Linux macOS
Suche überall (auch Branches, Commits) Shift + Shift (doppelt) Shift + Shift
Aktionen suchen Strg + Shift + A Cmd + Shift + A
Tool-Fenster wechseln Alt + [Zahl] Cmd + [Zahl]

Mit „Aktionen suchen" (Strg + Shift + A) kannst du jeden Git-Befehl finden, auch wenn du den Shortcut nicht kennst – tippe einfach „Commit", „Push", „Branch" usw. ein.

Shortcuts anpassen und eigene erstellen

Falls dir ein Shortcut nicht zusagt oder du einen fehlenden hinzufügen möchtest:

  1. Gehe zu File → Settings (bzw. PhpStorm → Settings auf macOS)
  2. Navigiere zu Keymap
  3. Suche nach der gewünschten Aktion (z. B. „Git Push")
  4. Rechtsklick → Add Keyboard Shortcut
  5. Drücke deine gewünschte Tastenkombination und bestätige

Du kannst auch eine komplett andere Keymap wählen (z. B. Eclipse oder Visual Studio), falls du von einer anderen IDE kommst.

Mein Empfohlenes „Starter-Set" 🎯

Wenn du nur fünf Shortcuts lernen möchtest, nimm diese:

  1. Strg + K – Commit-Dialog öffnen
  2. Strg + Shift + K – Push durchführen
  3. Strg + T – Pull/Update holen
  4. Strg + Shift + ` – Branches-Popup öffnen
  5. Strg + Alt + Z – Änderungen verwerfen (Rollback)

Mit diesen fünf Shortcuts deckst du etwa 80 % deiner täglichen Git-Interaktionen ab – und sparst dabei jede Menge Zeit. Die restlichen Shortcuts kommen dann nach und nach dazu, je nachdem welche Funktionen du häufiger nutzt.