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:

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

Push in PhpStorm durchführen

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

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

  2. Push-Dialog öffnen

    Es gibt mehrere Wege:

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

  3. Commits überprüfen

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

  4. Push ausführen

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

Was kann schiefgehen?

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

Pull – Änderungen herunterladen und integrieren 📥

Wann benutze ich Pull?

Du verwendest Pull immer dann, wenn du:

Was passiert bei einem Pull genau?

Ein git pull ist eigentlich eine Kombination aus zwei Befehlen:

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

Pull in PhpStorm durchführen

  1. Pull-Dialog öffnen

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

  2. Optionen prüfen

    Im Pull-Dialog siehst du:

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

  3. Pull ausführen

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

Die schnelle Alternative: Update Project

PhpStorm bietet auch eine komfortablere Option namens Update Project:

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

Push und Pull im Vergleich – eine Übersicht

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

Ein typischer Arbeitsablauf in der Praxis

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

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

Merke dir diese Faustregel:

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

Häufige Situationen und wie du damit umgehst

Situation 1: Push wird abgelehnt

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

Lösung:

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

Situation 2: Pull verursacht Merge-Konflikte

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

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

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

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

Lösung: Verwende Fetch statt Pull:

Zusammenfassung ✅

Push-Konflikte: Wenn GitHub „ahead" ist 🚧

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

Warum lehnt Git den Push ab?

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

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

Die typische Fehlermeldung sieht ungefähr so aus:

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

Das folgende Diagramm zeigt, wie diese Situation entsteht:

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

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

Die Lösung: Erst Pull, dann Push

Der Standard-Workflow in dieser Situation ist einfach:

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

In PhpStorm durchführen

  1. Pull durchführen

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

  2. Ergebnis prüfen

    Nach dem Pull gibt es drei mögliche Szenarien:

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

  3. Push erneut versuchen

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

Was passiert beim Pull genau?

Hinter den Kulissen macht git pull eigentlich zwei Dinge:

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

Nach einem erfolgreichen Pull sieht deine Historie so aus:

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

Wenn Konflikte auftreten

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

  1. Konflikt-Benachrichtigung

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

  2. Drei-Spalten-Editor nutzen

    Du siehst drei Spalten nebeneinander:

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

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

  3. Konflikt als gelöst markieren

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

  4. Merge-Commit abschließen

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

Alternative: Rebase statt Merge

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

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

Rebase in PhpStorm aktivieren

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

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

Wann Rebase, wann Merge?

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

Tipps zur Vermeidung dieser Situation

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

Zusammenfassung

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

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

Der Unterschied zwischen git fetch und git pull 🔄

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

Das Grundprinzip

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

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

git fetch – nur informieren, nichts verändern

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

Was passiert konkret?

Typische Ausgabe nach git fetch:

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

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

git pull – informieren und integrieren

git pull ist im Grunde zwei Befehle in einem:

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

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

Was passiert konkret?

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

Typische Ausgabe nach git pull:

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

Wann welchen Befehl verwenden?

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

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

Der typische Workflow mit git fetch

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

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

    git fetch

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

    git log main..origin/main --oneline

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

  3. Entscheiden und mergen – Wenn alles gut aussieht:

    git merge origin/main

So machst du es in PhpStorm

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

Fetch in PhpStorm

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

Pull in PhpStorm

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

Update Project – die komfortable Alternative

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

Was passiert bei Konflikten?

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

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

Zusammenfassung

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

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