Neueste Änderungen aus git abrufen

Klicke im Service-Panel auf Neueste Änderungen aus git abrufen. Wir holen die neuesten Commits aus deinem Repo und starten deine App (bei Web-Apps) neu.

Zuletzt aktualisiert am 23. Mai 2026

Noch nicht bereitgestellt? → Website aus einem git-Repo bereitstellen oder Web-App aus einem git-Repo bereitstellen

Nachdem eine Website oder App aus einem git-Repo bereitgestellt wurde, aktualisieren neue Commits in deinem Repo den Server nicht automatisch. Klicke auf Neueste Änderungen aus git abrufen, um den Server auf den aktuellen Stand zu bringen — mit einem Klick führen wir im Hintergrund git pull --ff-only aus und installieren (bei Web-Apps) neue Abhängigkeiten und starten deine App unter neu.

Wenn der Server hinter deinem Repo zurückliegt, zeigt die Karte der Workload auf der Startseite neben ihrem Status eine kleine **· ⤓ N behind**-Markierung — so siehst du sofort, dass es etwas abzurufen gibt. Bewege den Mauszeiger darüber, um den genauen Befehl zu sehen.

1. Service-Panel öffnen

Klicke auf der Startseite auf die Karte der Website oder App, die du aktualisieren möchtest. Das Service-Panel öffnet sich.

Klicke auf der Startseite auf die Website- oder App-Karte, um das Service-Panel zu öffnen

2. Tab „Steuerung“ öffnen und auf „Neueste Änderungen aus git abrufen“ klicken

Sowohl bei statischen Websites als auch bei Web-Apps findest du Neueste Änderungen aus git abrufen im Tab Steuerung, neben Neu starten / Stoppen / Starten / Deploy-Schlüssel generieren.

Tab „Steuerung“ für statische Website und Web-App — Neueste Änderungen aus git abrufen bei beiden

Der Button erscheint außerdem an zwei weiteren Stellen:

Statische Website — zusätzlich in der Symbolleiste des Tabs Dateien (⤓ Neueste Änderungen aus git abrufen), weil Nutzer statischer Websites dort oft arbeiten.
Beide Arten — im Tab Status, wenn neue Commits zum Abrufen vorhanden sind. Ein Banner „N Commits hinter origin“ erscheint mit einem Button zum Abrufen daneben. Nutze diese Ansicht, wenn du vor dem Abrufen genau sehen möchtest, was aussteht (Commit-Anzahl, aktuelle vs. Remote-SHA).

Der Status-Tab zeigt ein Banner „N Commits zurück“ mit einem Button zum Abrufen

3. Faro führt den Pull aus

Der Chat übernimmt. Bei einer statischen Website führen wir git pull --ff-only aus und liefert weiter aus — ein Neustart ist nicht nötig. Bei einer Web-App installieren wir außerdem neue Abhängigkeiten (npm ci / pip install) und starten deine App neu.

Der Chat zeigt die Pull-Schritte und die neue Commit-SHA

4. Fertig

Der Git-Statusbereich wird beim neuen Commit auf „Synchron“ aktualisiert.

Der Status-Tab zeigt beim neuen Commit jetzt „Synchron“

Wenn die Website nicht aus einem git-Repo bereitgestellt wurde

Faro prüft das zuerst und schreibt dir im Chat: „Diese Website wurde nicht aus einem git-Repo bereitgestellt, daher gibt es nichts abzurufen.“ Um die Dateien zu ersetzen, stelle sie mit Website von deinem Computer bereitstellen erneut bereit (oder mit dem entsprechenden Ablauf für Web-Apps) — ziehe einen frischen Ordner auf dieselbe Website, und wir ersetzen die vorhandenen Dateien.

Wenn der Pull mit „would be overwritten“ fehlschlägt

Wir verwenden git pull --ff-only; damit werden Nicht-Fast-Forward-Merges abgelehnt. Wenn irgendetwas auf dem Server eine getrackte Datei geändert hat — der Dateien-Tab, ein SFTP-Client wie FileZilla, eine SSH-Sitzung oder sogar die laufende App selbst — kann der Pull mit „Your local changes would be overwritten by merge“ fehlschlagen.

Der Bereich Git-Status im Status-Tab zeigt dir, was sich geändert hat:

M = eine getrackte Datei wurde auf dem Server bearbeitet. Konflikt mit Pull. Repo-Datei verwenden (verwirft deine lokale Änderung): Führe sudo git checkout -- <file> im Pfad der Workload aus und rufe dann erneut ab.
? = eine nicht getrackte Datei (z. B. von Nutzern hochgeladene Daten in uploads/, Laufzeitdateien, die deine App erstellt). Kein Konflikt — git pull lässt nicht getrackte Dateien in Ruhe. Keine Aktion erforderlich.

Bei privaten Repos: zuerst einen Deploy-Schlüssel generieren

Wenn du zum ersten Mal „Neueste Änderungen abrufen“ für ein privates Repo ausführst, funktionieren die zwischengespeicherten HTTPS-Zugangsdaten nicht für unbeaufsichtigte Pulls. Die Lösung ist ein einmaliger Deploy-Schlüssel.

Klicke im Service-Panel auf Deploy-Schlüssel generieren (neben „Neueste Änderungen abrufen“).
Faro generiert auf dem Server ein SSH-Schlüsselpaar und zeigt dir im Chat den öffentlichen Schlüssel.
Füge ihn in den Einstellungen deines Repos unter Deploy keys (GitHub) oder SSH keys (GitLab, Bitbucket, Codeberg, Gitea) ein. Lass Schreibzugriff DEAKTIVIERT — Lesezugriff reicht aus.
Antworte im Chat mit done — Faro stellt das git-Remote von HTTPS auf SSH um und testet es.

Danach funktioniert „Neueste Änderungen abrufen“, ohne erneut nach Zugangsdaten zu fragen.

Chat mit Generierung des Deploy-Schlüssels — Faro zeigt dir den öffentlichen Schlüssel, den du in die Einstellungen deines Repos einfügst

Monorepo- / Unterverzeichnis-Deployments

Wenn du aus einem Unterverzeichnis eines Monorepos bereitgestellt hast (z. B. apps/web), funktioniert „Neueste Änderungen abrufen“ trotzdem — sparse-checkout erledigt das im Hintergrund. Wir ziehen die Änderungen in den dauerhaft vorhandenen Klon unter /var/www/.helm-repos/<domain>/ (oder /opt/.helm-repos/<app>/ bei einer nativen Web-App), und dein Deploy-Verzeichnis ist ein Symlink, der automatisch auf die neuen Dateien zeigt.

Branch wechseln

„Neueste Änderungen abrufen“ zieht aus dem Branch, den du bei der ersten Bereitstellung geklont hast. Um zu einem anderen Branch zu wechseln, stelle die App über das Modal erneut bereit — wähle den neuen Branch unter Erweitert (git) aus.