# 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.