# Git & GitHub mit PhpStorm
Komplexe Projekte erfordern Versionsmanagement.
Als PDF: [https://li.fabula.vision/git-pdf](https://li.fabula.vision/git-pdf) | Hier geht es zum [Kurs für Fortgeschrittene](https://li.fabula.vision/git2).
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:
```mermaid
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:
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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 ` |
> ⚠️ **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:
```gitignore
# 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:
```
: (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:**
- **feat:** Neues Feature
- **fix:** Bugfix
- **refactor:** Code-Umbau ohne Funktionsänderung
- **docs:** Dokumentation
- **style:** Formatierung, keine Code-Änderung
- **test:** Tests hinzugefügt oder geändert
- **chore:** Wartungsarbeiten (Dependencies, Config, etc.)
---
## 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
```mermaid
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 ` | 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 ` | Neuen Branch erstellen und wechseln |
| 11 | `git switch ` | Zu Branch wechseln |
| 12 | `git merge ` | Branch zusammenführen |
| 13 | `git diff` | Änderungen anzeigen |
| 14 | `git restore ` | Ä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.
# 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:
- `projekt_final.php`
- `projekt_final_neu.php`
- `projekt_final_wirklich_final.php`
- `projekt_final_v2_korrigiert.php`
😅 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:
- **Änderungen speichern**
- **Frühere Zustände wiederherstellen**
- **Änderungen vergleichen**
- **Entwicklungsstände dokumentieren**
- **Paralleles Arbeiten ermöglichen**
- **Experimente in separaten Entwicklungszweigen erlauben**
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:
- Änderungen lokal auf deinem Rechner verwalten kannst
- in sinnvollen Schritten speichern kannst
- verschiedene Entwicklungsstände verwalten kannst
- mit anderen gemeinsam an einem Projekt arbeiten kannst
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:
- „Login-Formular erstellt“
- „Fehler bei Passwortprüfung behoben“
- „Navigation umgebaut“
- „Datenbankverbindung auf PDO umgestellt“
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:
- Du kannst mutiger arbeiten
- Du kannst Änderungen testen
- Du kannst notfalls zurückrollen
**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:
- welche Dateien geändert wurden
- *was* in diesen Dateien geändert wurde
- wann die Änderung passiert ist
- mit welcher Nachricht sie gespeichert wurde
Das ist extrem hilfreich, wenn du dich fragst:
- „Warum funktioniert diese Funktion heute anders als gestern?“
- „Wann habe ich diesen Code eingebaut?“
- „Welche Änderung hat wahrscheinlich den Bug verursacht?“
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:
- ein neues Feature bauen
- einen Bugfix testen
- ein Redesign ausprobieren
…ohne den stabilen Hauptstand direkt zu gefährden.
Das ist viel besser als:
- Dateien umzubenennen
- Ordner zu duplizieren
- Code auszukommentieren „für später“
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:
- in kleinen, sinnvollen Schritten arbeiten
- Änderungen bewusst dokumentieren
- neue Features getrennt entwickeln
- Bugs gezielt zurückverfolgen
- mit Online-Plattformen wie GitHub zusammenarbeiten
---
## Ein einfaches Alltagsbeispiel
Stell dir vor, du schreibst an einer Hausarbeit.
**Ohne Versionsverwaltung** würdest du vielleicht so arbeiten:
- `hausarbeit.docx`
- `hausarbeit_neu.docx`
- `hausarbeit_mit_korrektur.docx`
- `hausarbeit_final.docx`
- `hausarbeit_final_final.docx`
**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:
- „Zeig mir, was sich seit gestern geändert hat.“
- „Stell den Stand von vorgestern wieder her.“
- „Ich möchte eine alternative Version des Fazits ausprobieren.“
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:
- strukturiert zu arbeiten
- weniger Angst vor Fehlern zu haben
- Änderungen bewusst zu machen
- Projekte sauber aufzubauen
- später leichter mit GitHub und Teams zu arbeiten
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**:
- nur ein Backup-System
- nur für große Teams gedacht
- nur für Profis
- nur für Open-Source-Projekte
- dasselbe wie GitHub
**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:
- Chaos durch viele Dateikopien
- fehlende Rückgängig-Möglichkeiten
- unklare Änderungsverläufe
- riskante Experimente
- schwierige Zusammenarbeit
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*.
# 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:
- **Lokales Repository:** Liegt auf deinem Computer, nur du hast Zugriff.
- **Remote Repository:** Liegt auf einem Server (z. B. GitHub), kann von mehreren Personen genutzt werden.
> 💡 *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.
```text
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.
```mermaid
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.
```bash
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**:
- **Push** 📤: Du **sendest** deine lokalen Commits an das Remote-Repository (z. B. GitHub). Damit werden deine Änderungen für andere sichtbar bzw. gesichert.
- **Pull** 📥: Du **holst** die neuesten Änderungen vom Remote-Repository auf deinen Computer. Falls andere Personen Änderungen gepusht haben, bekommst du diese so.
```mermaid
flowchart LR
A["Lokales Repository
auf deinem PC"] -->|Push| B["Remote Repository
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.
# 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](https://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:
```bash
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)*
```bash
brew install git
```
Homebrew ist ein beliebter Paketmanager für macOS. Falls du ihn noch nicht hast, findest du ihn unter [brew.sh](https://brew.sh).
3. **Offizieller Installer**
Du kannst auch den Installer von [git-scm.com/downloads/mac](https://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:
- **Debian/Ubuntu:**
```bash
sudo apt update
sudo apt install git
```
- **Fedora:**
```bash
sudo dnf install git
```
- **Arch Linux:**
```bash
sudo pacman -S git
```
> 💡 **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:
```bash
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.
```bash
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:
```bash
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! 🚀
# 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:
- **Nachvollziehbarkeit:** In einem Projekt (egal ob allein oder im Team) kannst du später genau sehen, *wer* eine bestimmte Änderung gemacht hat. Das hilft beim Debugging und bei der Zusammenarbeit enorm.
- **Zuordnung auf Plattformen wie GitHub:** Wenn deine konfigurierte E-Mail-Adresse mit deinem GitHub-Konto verknüpft ist, werden deine Commits automatisch deinem Profil zugeordnet – inklusive Profilbild und Verlinkung.
- **Professionalität:** Commits mit „Unknown" oder einer kryptischen Kennung wirken unprofessionell und erschweren die Zusammenarbeit.
---
## 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:
```bash
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:
```bash
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:
```bash
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:
```bash
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:
```bash
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! 🎉
# 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:
```bash
# 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:
- **Neues Repository initialisieren:** Öffne ein Projekt ohne Git und wähle **VCS → Create Git Repository**. PhpStorm erstellt dann `.git` im Projektordner.
- **Bestehendes Repository öffnen:** Wenn du ein Projekt öffnest, das bereits ein `.git`-Verzeichnis enthält, aktiviert PhpStorm die Git-Integration automatisch.
- **Änderungen sehen:** Im Tab **Commit** (links oder unten, je nach Layout) siehst du alle geänderten Dateien. Hier kannst du Dateien stagen und committen.
- **Terminal nutzen:** Falls du doch mal einen Git-Befehl manuell eingeben möchtest, öffne das integrierte Terminal mit **Alt + F12** (Windows/Linux) bzw. **⌥ + F12** (macOS).
---
## 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.
# 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 ` 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:
- Die **gesamte Versionshistorie** deines Projekts
- Informationen über Branches, Commits und Konfigurationen
- Die Staging Area (auch „Index" genannt)
> ⚠️ **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**:
```mermaid
flowchart LR
A["📂 Working Directory
„Deine Dateien auf der Festplatte“"]
B["📋 Staging Area
„Vorgemerkt für den nächsten Commit“"]
C["🗄️ Repository
„Dauerhaft gespeicherte Versionen“"]
A -->|"git add
„Git → Add“ in PhpStorm"| B
B -->|"git commit
„Commit“ in PhpStorm"| C
```
---
## Was du jetzt hast
Nach diesen Schritten ist dein Projekt ein **vollwertiges lokales Git-Repository**. Du kannst ab sofort:
- Änderungen committen und eine Historie aufbauen
- Branches erstellen, um neue Features zu entwickeln
- Jederzeit zu früheren Versionen zurückkehren
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. 🎉
# 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:
```gitignore
# ===========================================
# 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:
>
> ```bash
> 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. 😊
# 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:
```mermaid
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:
- `index.php` – neues Kontaktformular hinzugefügt ✅
- `style.css` – Farben angepasst ✅
- `config.php` – versehentlich dein Datenbank-Passwort im Klartext eingetragen ❌
**Ohne Staging Area** würdest du alle drei Dateien auf einmal committen – inklusive des Passworts. 😬
**Mit Staging Area** machst du Folgendes:
```bash
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:
- saubere, thematisch getrennte Commits zu erstellen,
- Änderungen vor dem Festschreiben zu überprüfen,
- Fehler zu vermeiden, bevor sie in der Historie landen.
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.
# 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:
```mermaid
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:
- Gehe zu **Git → Show Git Log** (oder klicke unten auf den Tab *„Git"* und dann auf *„Log"*)
- Du siehst jetzt eine Liste aller Commits – bei deinem ersten Commit natürlich nur einen einzigen Eintrag
- Klickst du auf den Commit, zeigt dir PhpStorm an, welche Dateien enthalten sind und was geändert wurde
---
## 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:
```bash
git add
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.
# 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:
- **Kurz und prägnant** sein (idealerweise maximal 50–72 Zeichen)
- **Im Imperativ** formuliert sein (als würdest du Git einen Befehl geben)
- **Das „Was" beschreiben**, nicht das „Wie"
> 💡 **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:
- **Drücke Enter für eine neue Zeile**, um Betreff und Beschreibung zu trennen
- PhpStorm zeigt dir eine **Warnung**, wenn deine Betreffzeile zu lang wird (über 72 Zeichen)
- Du kannst unter **Settings → Version Control → Commit** einstellen, dass PhpStorm dich erinnert, wenn die Nachricht leer oder sehr kurz ist
- Mit **Strg+Shift+K** (bzw. **Cmd+Shift+K** auf macOS) öffnest du direkt das Commit-Fenster
---
## 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. 🚀
# 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:
```mermaid
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:
- **Commit-Nachricht** – die erste Zeile deiner Nachricht (deshalb ist eine aussagekräftige erste Zeile so wichtig!)
- **Autor** – wer den Commit gemacht hat
- **Datum und Uhrzeit** – wann der Commit erstellt wurde
- **Commit-Hash** – eine eindeutige ID (z. B. `a3b8f2c`), mit der du den Commit referenzieren kannst
- **Branch-Tags** – farbige Labels zeigen an, zu welchem Branch ein Commit gehört
> 💡 **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 **vollständige Commit-Nachricht** (auch mehrzeilige)
- Den **vollständigen Commit-Hash**
- Informationen über den **Autor** und den **Committer** (können unterschiedlich sein)
### 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:
- **Nach Text suchen:** Gib im Suchfeld einen Begriff ein, um Commits zu finden, deren Nachricht diesen Begriff enthält.
- **Nach Autor filtern:** Klicke auf das Filter-Symbol und wähle „User", um nur Commits eines bestimmten Autors zu sehen.
- **Nach Datum filtern:** Du kannst auch einen Zeitraum eingrenzen, z. B. „letzte Woche" oder ein bestimmtes Datum.
- **Nach Pfad filtern:** Besonders praktisch – du kannst die Historie auf eine **einzelne Datei oder einen Ordner** beschränken. Rechtsklicke dafür im Projektbaum auf eine Datei und wähle **Git → Show History for Selection**.
---
## 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. 🎯
# 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:
- **Dateien hinzufügen**, die du vergessen hattest
- **Dateien entfernen**, die versehentlich dabei waren
- **Die Commit-Nachricht ändern**
- **Änderungen an bereits enthaltenen Dateien ergänzen**
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
```mermaid
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:
```bash
git commit --amend
```
Oder, wenn du auch Dateien hinzufügen möchtest:
```bash
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.
# 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.
```mermaid
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:
- **Experimentieren ohne Risiko:** Du kannst neue Ideen ausprobieren, ohne deinen funktionierenden Code zu gefährden. Wenn das Experiment schiefgeht, löschst du einfach den Branch – dein `main`-Branch bleibt unberührt.
- **Paralleles Arbeiten:** Du kannst an mehreren Features oder Bugfixes gleichzeitig arbeiten, ohne dass sie sich gegenseitig in die Quere kommen. Jedes Feature lebt in seinem eigenen Branch.
- **Saubere Historie:** Statt einer endlosen Kette von Commits wie „Feature angefangen", „Feature weiter", „Bugfix zwischendurch", „Feature fertig" hast du klar getrennte Entwicklungsstränge, die du am Ende sauber zusammenführst.
- **Stabiler Hauptzweig:** Dein `main`-Branch bleibt immer in einem funktionierenden Zustand. Nur getestete, fertige Features werden dorthin überführt.
---
## 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:
```bash
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:
- „Kontaktformular HTML-Grundstruktur erstellt"
- „PHP-Validierung für Formularfelder hinzugefügt"
- „Erfolgsmeldung nach Absenden implementiert"
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:
```bash
git checkout main
git checkout -b bugfix/mobile-navigation
```
Du behebst den Fehler und committest:
- „Mobile Navigation: Hamburger-Menü funktioniert jetzt korrekt"
Dieser Fix ist dringend, also mergst du ihn direkt zurück in `main`:
```bash
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:
```bash
git checkout feature/kontaktformular
```
Sobald das Kontaktformular fertig und getestet ist, führst du es mit `main` zusammen:
```bash
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.
```mermaid
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. 🎯
# 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:
```mermaid
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:**
- Der **HEAD-Zeiger** (das ist Git's Markierung für „wo bin ich gerade?") wird auf den neuen Branch gesetzt.
- Deine **Dateien im Arbeitsverzeichnis** werden automatisch auf den Stand des Ziel-Branches gebracht.
- Alle **offenen Dateien in PhpStorm** aktualisieren sich entsprechend – du siehst sofort den Code des neuen Branches.
---
## 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. 🎯
# 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:
```mermaid
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**):
- Du siehst einen neuen **Merge-Commit**, der die beiden Entwicklungslinien zusammenführt.
- Die Commit-Historie zeigt, dass die Commits aus dem Feature-Branch nun auch im Main-Branch enthalten sind.
---
## Was passiert im Hintergrund?
Wenn du in PhpStorm „Merge into Current" auswählst, führt Git im Hintergrund folgenden Befehl aus:
```bash
git merge login-formular
```
Dabei erstellt Git (je nach Situation) entweder:
- Einen **Merge-Commit**, der beide Branches zusammenführt und als „Knotenpunkt" in der Historie sichtbar ist.
- Einen **Fast-Forward-Merge**, wenn der Main-Branch seit der Erstellung des Feature-Branches keine eigenen Änderungen hatte. In diesem Fall wird kein extra Merge-Commit erstellt – die Commits werden einfach „vorgeschoben".
---
## 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. 🎉
# 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:
- **Zwei Branches bearbeiten dieselbe Codezeile:** Du änderst in deinem Feature-Branch eine Funktion, während jemand (oder du selbst) im Main-Branch dieselbe Zeile ebenfalls angepasst hat.
- **Eine Datei wird in einem Branch gelöscht, im anderen bearbeitet:** Git weiß nicht, ob die Datei weg soll oder die Bearbeitung wichtig ist.
- **Parallele Arbeit an derselben Datei:** Selbst wenn du alleine arbeitest, kann das passieren, wenn du z. B. einen Hotfix direkt im Main-Branch machst, während du parallel an einem Feature arbeitest.
### 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:
```php
$siteTitle = "Meine Website";
```
Jetzt passiert Folgendes:
1. Im **Main-Branch** änderst du die Zeile zu:
```php
$siteTitle = "Meine tolle Website";
```
2. Im **Feature-Branch** (den du vorher vom Main-Branch abgezweigt hast) änderst du dieselbe Zeile zu:
```php
$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.
```mermaid
flowchart TD
A["Ursprung
$siteTitle = Meine Website"] --> B["Main-Branch
$siteTitle = Meine tolle Website"]
A --> C["Feature-Branch
$siteTitle = Mein Webprojekt"]
B --> D["Merge-Versuch"]
C --> D
D --> E["Konflikt!
Git weiss nicht,
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.:
```php
$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
- **Keine Panik!** Ein Konflikt bedeutet nicht, dass etwas kaputt ist – Git bittet dich nur um eine Entscheidung, die es selbst nicht treffen kann.
- **Verstehe beide Versionen:** Bevor du eine Version wählst, schau dir an, *warum* die Änderung gemacht wurde. Manchmal ist die beste Lösung eine Kombination aus beiden.
- **Teste nach dem Merge:** Nachdem du Konflikte gelöst hast, teste dein Projekt gründlich. Syntaktisch kann alles korrekt aussehen, aber logisch kann etwas nicht zusammenpassen.
- **Konflikte vermeiden:** Je öfter du deine Branches synchronisierst (regelmäßig `main` in deinen Feature-Branch mergen), desto kleiner und seltener werden Konflikte.
- **Im Zweifel: Abbrechen:** Wenn du dir unsicher bist, kannst du den Merge jederzeit mit **Git → Abort Merge** abbrechen. Alles bleibt beim Alten, und du kannst dich in Ruhe vorbereiten.
---
## 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.
# 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](https://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:
- **Professionalität vs. Kreativität:** Wenn du GitHub auch für berufliche Zwecke nutzen möchtest (Bewerbungen, Portfolio, Open-Source-Beiträge), empfiehlt sich ein **seriöser, wiedererkennbarer Name**. Kombinationen aus Vor- und Nachname funktionieren gut, z. B. `maxmustermann` oder `m-mustermann`. Namen wie `xXx_CoderKing_xXx` wirken weniger professionell.
- **Einzigartigkeit:** Der Name muss auf GitHub einzigartig sein. Beliebte Namen sind oft schon vergeben – sei also kreativ, aber bleib lesbar.
- **Änderbarkeit:** Du kannst deinen Benutzernamen später ändern, aber das hat Konsequenzen: Alle URLs zu deinen Repositories ändern sich, und Links von außen führen ins Leere. Wähle also möglichst von Anfang an einen Namen, mit dem du langfristig zufrieden bist.
> 💡 **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:
- **Name:** Dein vollständiger oder angezeigter Name (unabhängig vom Benutzernamen).
- **Bio:** Eine kurze Beschreibung von dir – was du machst, welche Technologien dich interessieren.
- **Location:** Optional dein Standort.
- **Website/Social Links:** Hier kannst du auf dein Portfolio, LinkedIn oder andere Profile verlinken.
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:
- **Primary email:** Die Haupt-E-Mail-Adresse für Benachrichtigungen und Account-Wiederherstellung.
- **Keep my email addresses private:** Diese Option solltest du **aktivieren**, wenn du nicht möchtest, dass deine echte E-Mail-Adresse in Commits öffentlich sichtbar ist. GitHub stellt dir dann eine anonymisierte Adresse zur Verfügung (z. B. `123456+deinname@users.noreply.github.com`), die du in deiner lokalen Git-Konfiguration verwenden kannst.
- **Block command line pushes that expose my email:** Verhindert, dass du versehentlich Commits mit deiner echten E-Mail hochlädst.
> ⚠️ **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**:
- 2FA schützt deinen Account, selbst wenn dein Passwort kompromittiert wird.
- GitHub unterstützt Authenticator-Apps (z. B. Google Authenticator, Authy, 1Password) und Hardware-Keys.
- Ohne 2FA kannst du bei manchen Aktionen eingeschränkt sein (z. B. bei der Nutzung von GitHub Actions in bestimmten Organisationen).
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:
- **SSH-Keys:** Eine sichere Methode, bei der du einen Schlüssel auf deinem Computer generierst und den öffentlichen Teil bei GitHub hinterlegst. Das ermöglicht passwortloses Pushen und Pullen.
- **Personal Access Tokens (PAT):** Wenn du HTTPS statt SSH nutzt, brauchst du ein Token anstelle deines Passworts. Diese Tokens kannst du unter **Developer settings → Personal access tokens** erstellen.
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:
```mermaid
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"]
```
- **Repositories:** Hier siehst du alle deine Projekte und kannst neue anlegen.
- **Your profile:** Deine öffentliche Profilseite mit deinen Repositories, Beiträgen und Aktivitäten.
- **Explore:** Entdecke interessante Open-Source-Projekte.
- **Settings:** Alle Account- und Sicherheitseinstellungen.
---
## 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! 🚀
# 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:
- **Privater Schlüssel** (*Private Key*): Dieser bleibt **ausschließlich auf deinem Computer** und wird niemals weitergegeben. Er ist wie der Schlüssel zu deiner Haustür – nur du besitzt ihn.
- **Öffentlicher Schlüssel** (*Public Key*): Diesen gibst du an Dienste wie GitHub weiter. Er ist wie ein spezielles Schloss, das nur mit deinem privaten Schlüssel geöffnet werden kann.
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.
```mermaid
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:
- **Windows**: Nutze **Git Bash** (wird mit Git installiert), **PowerShell** oder das **Windows Terminal**.
- **macOS**: Öffne die **Terminal**-App (findest du unter Programme → Dienstprogramme).
- **Linux**: Öffne dein bevorzugtes Terminal.
### 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:
```bash
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**:
```bash
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:
- `~/.ssh/id_ed25519` – dein **privater Schlüssel** (niemals teilen!)
- `~/.ssh/id_ed25519.pub` – dein **öffentlicher Schlüssel** (kommt zu GitHub)
### 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:**
```bash
eval "$(ssh-agent -s)"
```
Du siehst eine Ausgabe wie `Agent pid 12345` – der Agent läuft jetzt.
**Auf Windows (Git Bash):**
```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:**
```bash
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:
```bash
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:
> ```bash
> pbcopy < ~/.ssh/id_ed25519.pub
> ```
>
> **Auf Windows (Git Bash):**
> ```bash
> clip < ~/.ssh/id_ed25519.pub
> ```
### Schritt 2: Key in GitHub einfügen
1. Öffne [github.com](https://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:
```bash
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:
```bash
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:
```bash
git remote set-url origin git@github.com:dein-username/dein-repository.git
```
Prüfe die Änderung mit:
```bash
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:
- **Key nicht zum SSH-Agent hinzugefügt**: Führe `ssh-add ~/.ssh/id_ed25519` erneut aus.
- **Falscher Key bei GitHub hinterlegt**: Überprüfe auf GitHub unter *Settings → SSH and GPG keys*, ob der richtige öffentliche Schlüssel eingetragen ist.
- **Falscher Dateiname**: Wenn du den Key unter einem anderen Namen gespeichert hast, musst du diesen explizit angeben.
### 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:
```powershell
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:
```bash
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:
```mermaid
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. 🚀
# 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:
```mermaid
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](https://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](https://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):
```bash
git remote add origin https://github.com/dein-benutzername/mein-webprojekt.git
```
Oder mit SSH:
```bash
git remote add origin git@github.com:dein-benutzername/mein-webprojekt.git
```
3. Überprüfe, ob die Remote korrekt hinzugefügt wurde:
```bash
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:
```bash
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](https://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:
```mermaid
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:**
- Überprüfe, ob dein SSH-Key bei GitHub hinterlegt ist (unter [github.com/settings/keys](https://github.com/settings/keys))
- Teste die Verbindung mit `ssh -T git@github.com`
- Alternativ: Wechsle zu HTTPS, bis du SSH korrekt eingerichtet hast
### „Repository not found"
Entweder existiert das Repository nicht, der Name ist falsch geschrieben, oder du hast keine Zugriffsrechte (bei privaten Repositories).
**Lösung:**
- Überprüfe die URL auf Tippfehler
- Stelle sicher, dass du bei GitHub angemeldet bist
- Bei privaten Repos: Prüfe, ob dein Account Zugriff hat
---
## 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.
# 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.
```mermaid
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:
- Neue Commits gemacht hast, die du auf GitHub sichern möchtest
- Deinen Code von einem anderen Gerät aus zugänglich machen willst
- Anderen Personen (bei Teamarbeit) deine Änderungen zur Verfügung stellen möchtest
- Ein Backup in der Cloud haben willst
> 💡 **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:
- An mehreren Geräten arbeitest und die Änderungen vom anderen Gerät holen möchtest
- Mit anderen im Team arbeitest und deren Commits integrieren willst
- Vor dem Push sicherstellen möchtest, dass du auf dem neuesten Stand bist
- Nach einer Pause am Projekt weitermachen willst
### Was passiert bei einem Pull genau?
Ein `git pull` ist eigentlich eine **Kombination aus zwei Befehlen**:
```mermaid
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**:
- **Tastenkombination:** `Ctrl + T` (führt direkt Update aus, wenn so konfiguriert)
- **Menü:** **Git → 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:
```mermaid
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:
- Menü: **Git → Fetch**
- Das lädt die Informationen herunter, ändert aber nichts an deinen lokalen Dateien. Im Git-Log siehst du dann, ob „origin/main" weiter ist als dein lokaler „main".
---
## Zusammenfassung ✅
- **Push** = Hochladen: Schickt deine lokalen Commits an das Remote-Repository (z. B. GitHub)
- **Pull** = Herunterladen + Integrieren: Holt Commits vom Remote und fügt sie in deinen lokalen Branch ein
- Beide Befehle sind in PhpStorm bequem über Menü, Toolbar oder Tastenkürzel erreichbar
- **Reihenfolge beachten:** Im Zweifel erst Pull, dann Push – so vermeidest du Ablehnungen
- Pull kann Merge-Konflikte verursachen, wenn dieselben Stellen geändert wurden – diese lassen sich in PhpStorm komfortabel lösen
# 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:
```mermaid
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**:
```mermaid
flowchart LR
A["git pull"] --> B["git fetch\n- Aenderungen herunterladen"]
B --> C["git merge\n- Aenderungen integrieren"]
```
- **Fetch:** Lädt die neuen Commits vom Server herunter, ohne sie direkt in deinen Branch zu integrieren.
- **Merge:** Führt die heruntergeladenen Commits mit deinem lokalen Branch zusammen.
Nach einem erfolgreichen Pull sieht deine Historie so aus:
```mermaid
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:
```mermaid
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:
- **Regelmäßig pullen:** Bevor du anfängst zu arbeiten, ziehe dir erst die neuesten Änderungen. Das reduziert die Wahrscheinlichkeit von Konflikten.
- **Häufig pushen:** Je öfter du deine Änderungen hochlädst, desto kleiner sind die Unterschiede zwischen lokal und remote.
- **Kommunikation im Team:** Wenn mehrere Personen an denselben Dateien arbeiten, sprecht euch ab, wer wann welche Bereiche bearbeitet.
- **Feature-Branches nutzen:** Arbeite in separaten Branches statt direkt auf `main`. So vermeidest du Konflikte mit anderen, bis du bewusst mergst.
---
## 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. 😊
# 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
```mermaid
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?**
- Git verbindet sich mit GitHub und schaut nach, welche neuen Commits es dort gibt
- Diese Informationen werden heruntergeladen und in `origin/main` (oder entsprechend `origin/`) gespeichert
- Dein lokaler `main`-Branch und deine Arbeitsdateien bleiben **unangetastet**
**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:
```bash
git fetch
```
2. **Vergleichen** – Schau dir an, was sich geändert hat:
```bash
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:
```bash
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:
- **Merge incoming changes into the current branch** – entspricht `git pull` mit Merge
- **Rebase the current branch on top of incoming changes** – fortgeschrittene Option
- Du kannst auch wählen, ob PhpStorm vorher automatisch uncommittete Änderungen „stashen" soll
---
## 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.
- Bei `git fetch` allein passiert das **nie**, weil keine Änderungen integriert werden
- Bei `git pull` kann der Konflikt **sofort** auftreten, und du musst ihn lösen, bevor du weiterarbeiten kannst
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.
# Ä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 -- ` oder in neueren Git-Versionen `git restore `. In PhpStorm musst du dir diese Befehle aber nicht merken – du nutzt einfach die **Rollback**-Funktion.
```mermaid
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**:
- **Rollback** verwirft Änderungen, die du gemacht hast, aber **noch nicht committed** hast
- **Revert** erstellt einen neuen Commit, der die Änderungen eines **bereits existierenden Commits** rückgängig macht
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. 😉
# 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:
```mermaid
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).
```bash
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.
```bash
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!
```bash
git reset --hard HEAD~1 # Letzten Commit UND alle Änderungen komplett löschen
```
### Was bedeutet `HEAD~1`?
- `HEAD` zeigt auf deinen aktuellen Commit
- `HEAD~1` bedeutet „ein Commit vor HEAD"
- `HEAD~3` würde drei Commits zurückgehen
- Du kannst auch einen konkreten Commit-Hash angeben: `git reset --soft abc1234`
### 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:
```mermaid
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
```bash
# 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:
```bash
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:**
```bash
git revert a1b2c3d
```
Oder in PhpStorm: Rechtsklick auf den Commit → **Revert Commit**
3. **Den Revert-Commit pushen:**
```bash
git push
```
4. **Fertig!** Die Debug-Änderungen sind rückgängig gemacht, und die Historie zeigt transparent, was passiert ist.
---
## Zusammenfassung 📋
- **`reset`** schreibt die Historie um – ideal für lokale Commits, die noch niemand gesehen hat
- **`revert`** erstellt einen neuen „Rückgängig-Commit" – sicher für bereits gepushte Commits
- **Faustregel:** Sobald ein Commit gepusht wurde, nutze `revert`
- **Force Push** nur im Notfall und nur bei Solo-Projekten
- PhpStorm bietet für beide Methoden komfortable Menüoptionen im Git-Log
# 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:
- Die **gesamte Commit-Historie** durchsuchen
- Jeden **alten Commit auschecken** und die Datei dort finden
- Mit Befehlen wie `git log -p` oder `git show` den **kompletten Inhalt** jeder jemals existierenden Dateiversion sehen
> 💡 **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:
- **Passwort ändern** – logge dich ein und ändere das Passwort
- **API-Key rotieren** – erstelle einen neuen Key und deaktiviere den alten
- **Token widerrufen** – bei OAuth-Tokens, Personal Access Tokens etc.
> ⚠️ **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**
```bash
# 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**
```bash
# Entfernt die Datei "config/secrets.php" aus ALLEN Commits
git filter-repo --path config/secrets.php --invert-paths
```
3. **Änderungen auf GitHub pushen**
```bash
# 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](https://rtyley.github.io/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**
```bash
# 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**
```bash
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](https://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:
- Ihren lokalen Klon **löschen und neu klonen**, oder
- Mit `git fetch --all` und `git reset --hard origin/main` synchronisieren
> ⚠️ Wenn jemand einen alten Klon hat und pusht, könnten die sensiblen Daten wieder ins Repository gelangen!
---
## Zusammenfassung als Checkliste
```mermaid
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:
```gitignore
# 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:
```php
// ❌ Schlecht
$password = "geheim123";
// ✅ Gut
$password = getenv('DB_PASSWORD');
```
3. **Pre-Commit-Hooks einrichten** – Tools wie [git-secrets](https://github.com/awslabs/git-secrets) oder [pre-commit](https://pre-commit.com/) 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.
# 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
```mermaid
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.
```bash
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.:
- `feature/newsletter-anmeldung`
- `fix/login-redirect`
- `experiment/neues-layout`
### 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:**
- Du hast eine neue Funktion fertiggestellt (auch wenn sie klein ist)
- Du hast einen Bug behoben
- Du hast Refactoring abgeschlossen
- Du machst eine Pause oder wechselst das Thema
- Du hast etwas zum Laufen gebracht, das vorher nicht funktionierte
**Schlechte Zeitpunkte für einen Commit:**
- Der Code kompiliert/funktioniert nicht
- Du bist „mittendrin" in einer Änderung
- Du hast zehn verschiedene Dinge gleichzeitig geändert
> 💡 **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.
```bash
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.
# 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:
- **Halbfertiger Code im Hauptbranch:** Du fängst ein Feature an, bist mittendrin – und plötzlich musst du einen dringenden Bug fixen. Jetzt ist dein `main` in einem unbrauchbaren Zwischenzustand.
- **Schwierige Fehlersuche:** Wenn alles in einem langen Strang von Commits liegt, ist es schwerer nachzuvollziehen, welche Änderungen zu welchem Feature gehören.
- **Kein einfaches Verwerfen:** Stellst du fest, dass ein Experiment nicht funktioniert, musst du mühsam einzelne Commits rückgängig machen, statt einfach einen Branch zu löschen.
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.
```mermaid
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:
- Schreibe Code, teste, verbessere.
- **Committe regelmäßig** kleine, in sich abgeschlossene Schritte – nicht erst am Ende alles auf einmal.
- Schreibe aussagekräftige Commit-Nachrichten, wie du es gelernt hast.
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:
- **Git → Push** oder `Ctrl+Shift+K` (Windows) / `Cmd+Shift+K` (Mac).
### 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
```mermaid
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. 🚀
# 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:
- **To-Do-Liste:** Jedes Feature, das du irgendwann einbauen möchtest, wird ein Issue. So vergisst du nichts und hast immer einen klaren Überblick, was noch ansteht.
- **Bug-Dokumentation:** Wenn dir ein Fehler auffällt, den du gerade nicht beheben kannst, erstellst du ein Issue mit einer kurzen Beschreibung. Später weißt du sofort, worum es ging.
- **Ideensammlung:** Vage Ideen, die du „irgendwann mal" umsetzen willst, parken perfekt in einem Issue – besser als in einem Notizzettel, der verloren geht.
### 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:
```mermaid
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:
- Du siehst **auf einen Blick**, wie viel „in der Pipeline" ist
- Du kannst Issues per **Drag & Drop** zwischen Spalten verschieben
- Es zwingt dich, **fokussiert** zu bleiben – wenn „In Arbeit" zu voll wird, merkst du sofort, dass du dich verzettelst
### 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
- **Klare Meilensteine:** Ein Release markiert einen funktionierenden Stand. Wenn du später etwas kaputt machst, weißt du genau, welche Version noch funktioniert hat.
- **Changelog führen:** In der Release-Beschreibung dokumentierst du, was sich seit der letzten Version geändert hat. Das hilft dir (und eventuellen Nutzern), den Überblick zu behalten.
- **Archiv für stabile Versionen:** Du kannst jederzeit auf eine frühere Release-Version zurückgreifen – nicht nur im Git-Log graben, sondern direkt ein fertiges Paket herunterladen.
### 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:
- Installationsanleitungen
- Architektur-Entscheidungen
- Notizen zu Konfigurationsoptionen
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:
- **Automatische Tests** laufen lassen bei jedem Push
- **Code-Qualität** prüfen (z. B. mit PHP_CodeSniffer oder PHPStan)
- **Deployments** automatisieren (z. B. auf einen Webserver)
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:
```mermaid
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.
# 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:
```mermaid
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:
- **Branch-Name anzeigen:** Du siehst sofort, auf welchem Branch du gerade arbeitest
- **Branch wechseln:** Ein Klick öffnet das Branch-Popup mit allen lokalen und Remote-Branches
- **Neuen Branch erstellen:** Direkt aus dem Popup heraus
- **Branch-Aktionen:** Merge, Rebase, Rename, Delete – alles per Rechtsklick auf einen Branch
```mermaid
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:
- **Commit-Graph:** Visualisiert Branches und Merges als Linien
- **Commit-Details:** Autor, Datum, Nachricht auf einen Blick
- **Diff-Ansicht:** Klick auf einen Commit zeigt alle Änderungen
- **Suche und Filter:** Nach Autor, Datum, Nachricht oder Datei filtern
- **Branch-Filter:** Nur bestimmte Branches anzeigen
### Local Changes / Changes-Tab 📝
Zeigt alle **aktuell geänderten Dateien** – also alles, was seit dem letzten Commit verändert wurde:
- **Unversioned Files:** Neue Dateien, die noch nicht getrackt werden
- **Modified Files:** Geänderte Dateien
- **Staging-Funktion:** Dateien per Checkbox zur Staging Area hinzufügen
- **Diff-Vorschau:** Doppelklick zeigt die Änderungen im Detail
### 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:
- **Änderung anzeigen:** Zeigt den Diff für diese Stelle
- **Rollback:** Setzt nur diese Änderung zurück (nicht die ganze Datei!)
- **Copy old text:** Kopiert den ursprünglichen Text in die Zwischenablage
> 💡 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:
- **Update Project** (blauer Pfeil nach unten): Holt Änderungen vom Remote
- **Commit** (grüner Haken): Öffnet das Commit-Fenster
- **Push** (grüner Pfeil nach oben): Pusht Commits zum Remote
- **History** (Uhr-Symbol): Zeigt die Historie der aktuellen Datei
- **Rollback** (gekrümmter Pfeil): Verwirft Änderungen
---
## Das Commit-Fenster im Detail
Das Commit-Fenster (`Strg + K` / `Cmd + K`) verdient besondere Aufmerksamkeit, weil du es **am häufigsten** nutzen wirst:
```mermaid
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:**
- **Dateien selektiv auswählen:** Nicht alle geänderten Dateien müssen in einen Commit
- **Diff vor dem Commit prüfen:** Doppelklick auf eine Datei zeigt die Änderungen
- **Amend-Checkbox:** Letzten Commit korrigieren statt neuen erstellen
- **Commit and Push:** Beides in einem Schritt erledigen
---
## 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
6. **Neuen Branch erstellen** (Statusleiste → New Branch)
Für jedes neue Feature oder Experiment.
7. **Merge** (Git-Menü oder Branch-Popup)
Wenn ein Feature fertig ist, mergst du es zurück.
8. **Git Log** (Git-Tool-Fenster)
Um die Historie zu durchsuchen oder alte Commits zu finden.
9. **Rollback** (Editor-Gutter oder Kontextmenü)
Um Änderungen zu verwerfen, die du doch nicht willst.
10. **Show History** (Kontextmenü auf einer Datei)
Um zu sehen, wie sich eine bestimmte Datei entwickelt hat.
### Gelegentlich genutzt
11. **Amend Commit** (Checkbox im Commit-Fenster)
Wenn du den letzten Commit korrigieren musst.
12. **Git Blame / Annotate** (Kontextmenü)
Um herauszufinden, wer eine bestimmte Zeile geschrieben hat.
13. **Stash / Unstash** (Git-Menü)
Um Änderungen temporär beiseitezulegen.
14. **Cherry-Pick** (Rechtsklick auf Commit im Log)
Um einzelne Commits in einen anderen Branch zu übernehmen.
15. **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! 🚀
# 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:
- **Blaue Markierung:** Diese Zeilen wurden geändert
- **Grüne Markierung:** Diese Zeilen sind neu hinzugekommen
- **Kleines Dreieck:** Hier wurden Zeilen gelöscht
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:
- **Farbige Hervorhebung:** Geänderte, hinzugefügte und entfernte Zeilen sind farblich markiert
- **Pfeile zwischen den Spalten:** Ermöglichen das Übernehmen von Änderungen in die eine oder andere Richtung
- **Navigations-Pfeile oben:** Springen zur nächsten/vorherigen Änderung (`F7` / `Shift + F7`)
> 💡 **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:
- Einen Bug im Login-System gefixt
- Nebenbei einen Kommentar verbessert
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
```mermaid
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 ✅
- Die **Diff-Ansicht** zeigt dir präzise, was sich seit dem letzten Commit geändert hat – entweder per Doppelklick im Commit-Fenster oder über die farbigen Markierungen direkt im Editor.
- Du kannst **einzelne Chunks** (Änderungsblöcke) auswählen und damit **logisch zusammengehörige Änderungen** separat committen.
- Das führt zu einer **sauberen, nachvollziehbaren Git-Historie**, in der jeder Commit genau eine Sache macht.
- PhpStorm macht diesen Prozess besonders komfortabel durch die visuelle Darstellung mit Checkboxen neben jedem Chunk.
> 💡 **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.
# 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.