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. 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 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. 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 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. 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: flowchart LR A["git pull"] --> B["git fetch\nÄnderungen herunterladen"] B --> C["git merge\nÄnderungen integrieren"] Fetch: Git lädt die neuen Commits vom Remote herunter, ohne sie direkt anzuwenden Merge: Git integriert diese Commits in deinen aktuellen Branch Pull in PhpStorm durchführen 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 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) 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: 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: Führe zuerst einen Pull aus Löse eventuelle Merge-Konflikte (falls vorhanden) 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: 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: Hole die Remote-Änderungen mit git pull Löse eventuelle Konflikte (falls dieselben Stellen geändert wurden) Pushe dann erneut deine kombinierten Änderungen In PhpStorm durchführen 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. 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). Push erneut versuchen Nach erfolgreichem Pull gehst du zu Git → Push (oder Ctrl+Shift+K bzw. Cmd+Shift+K). Jetzt sollte der Push funktionieren. Was passiert beim Pull genau? Hinter den Kulissen macht git pull eigentlich zwei Dinge: flowchart LR A["git pull"] --> B["git fetch\n- Aenderungen herunterladen"] B --> C["git merge\n- Aenderungen integrieren"] 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: 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: Konflikt-Benachrichtigung PhpStorm meldet, dass Konflikte aufgetreten sind und fragt, ob du sie lösen möchtest. Klicke auf Merge oder Resolve. 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. Konflikt als gelöst markieren Sobald du fertig bist, klickst du auf Apply. PhpStorm markiert den Konflikt als gelöst. Merge-Commit abschließen Nachdem alle Konflikte gelöst sind, fordert PhpStorm dich auf, den Merge-Commit abzuschließen. Bestätige dies, und dann kannst du pushen. Alternative: Rebase statt Merge Neben dem klassischen Merge gibt es noch eine andere Strategie namens Rebase. Dabei werden deine lokalen Commits so umgeschrieben, als hättest du sie nach den Remote-Änderungen gemacht. Das ergibt eine lineare Historie ohne Merge-Commits: flowchart LR A["Commit A"] --> B["Commit B"] --> X["Commit X\n- von GitHub"] --> C2["Commit C\n- deine Arbeit, neu aufgesetzt"] Rebase in PhpStorm aktivieren Gehe zu Git → Pull Im Pull-Dialog aktiviere die Option Rebase (statt Merge) 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: Die Informationen über den Zustand des Remote-Repositories – also welche Commits dort existieren Den tatsächlichen Zustand deiner lokalen Arbeitsdateien – also dein Working Directory und dein lokaler Branch flowchart TB subgraph Remote ["☁️ GitHub"] RC["Remote Commits"] end subgraph Lokal ["💻 Dein Computer"] TRACK["Remote-Tracking Branch\n(origin/main)"] LOCAL["Lokaler Branch\n(main)"] WD["Working Directory\nDeine Dateien"] end RC -->|git fetch| TRACK TRACK -->|git merge| LOCAL LOCAL --> WD RC -->|git pull| TRACK RC -->|git pull| LOCAL RC -->|git pull| WD git fetch – nur informieren, nichts verändern Mit git fetch holst du dir die neuesten Informationen vom Remote-Repository, aber deine lokalen Branches und Dateien bleiben komplett unverändert. Git aktualisiert lediglich die sogenannten Remote-Tracking-Branches (z. B. origin/main), die wie ein Spiegel des Remote-Zustands funktionieren. Was passiert konkret? 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? Git führt zunächst einen fetch durch Anschließend werden die neuen Commits automatisch in deinen lokalen Branch gemergt 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: Fetch ausführen – Hole die neuesten Informationen: git fetch Vergleichen – Schau dir an, was sich geändert hat: git log main..origin/main --oneline Das zeigt dir alle Commits, die auf origin/main sind, aber noch nicht in deinem lokalen main. Entscheiden und mergen – Wenn alles gut aussieht: git merge origin/main So machst du es in PhpStorm PhpStorm bietet dir beide Optionen komfortabel über die Benutzeroberfläche an. Fetch in PhpStorm Gehe im Menü zu Git → Fetch (oder nutze die Tastenkombination, die du in den Einstellungen findest) PhpStorm verbindet sich mit GitHub und aktualisiert die Remote-Tracking-Branches Im Git-Log (unten im Git-Tool-Fenster) siehst du nun, ob origin/main weiter ist als dein lokaler main Du erkennst das an einer Anzeige wie „main ← 3 commits behind origin/main" Pull in PhpStorm Gehe im Menü zu Git → Pull (oder klicke auf den blauen Pfeil nach unten in der Toolbar) 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) 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.