Back to Blog

Vom SFTP-Upload zum Git-Deploy

Am Anfang habe ich meine Website per Termius und SFTP auf den VPS kopiert. Das war für den Start okay, aber inzwischen ist GitHub die zentrale Quelle: lokal bearbeiten, committen, pushen, und auf dem Server per git pull aktualisieren.

Der wichtigste Unterschied: Der VPS ist nicht mehr der Ort, an dem ich Website-Dateien direkt bearbeite. Er zieht nur noch den Stand, der vorher sauber in Git gelandet ist.

Warum ich umgestellt habe

Der erste Deploy-Weg war simpel: lokal Dateien bearbeiten, Termius öffnen, per SFTP auf den Ubuntu-VPS verbinden und die geänderten Dateien nach /var/www/newwaves.dev/ kopieren. Für eine kleine statische Website aus HTML, CSS, JavaScript und Bildern reicht das technisch aus.

Das Problem ist nicht die Technik, sondern die Kontrolle. Beim manuellen Kopieren ist schnell unklar, welche Datei wirklich neuer ist, ob auf dem Server noch ein alter Stand liegt oder ob man versehentlich etwas überschreibt. Außerdem fehlt eine nachvollziehbare Historie.

  • Git zeigt mir genau, welche Dateien geändert wurden.
  • Commits speichern nachvollziehbare Zwischenstände.
  • GitHub ist die zentrale Quelle zwischen Workstation und VPS.
  • Der VPS zieht nur noch fertige Stände und wird nicht mehr manuell per SFTP gepflegt.

Die neue Richtung

Der aktuelle lokale Projektordner auf der Workstation ist C:\Users\user0\Desktop\Projekte\newwaves.dev. Von dort aus wird die Website bearbeitet und später zu GitHub gepusht.

Im Repository bleiben nur die Dateien, die zur Website oder zur Projektdokumentation gehören. Lokale Abhängigkeiten, Build-Ausgaben und geheime Konfigurationen werden über .gitignore ausgeschlossen. Der Dokumentationsordner doku/ ist aktuell ebenfalls lokal ausgeschlossen. 

doku/
.env
node_modules/
dist/
build/

Der grundsätzliche Weg bleibt dadurch sehr einfach:

Workstation GitHub VPS

GitHub per SSH

GitHub wird per SSH angesprochen. Das lokale Repository zeigt auf diese Remote-URL: 

git@github.com:new-waves/newwaves.dev.git

Auf der Workstation liegt ein SSH-Key im Windows-Benutzerprofil. Git nutzt diesen Key, um sich bei GitHub zu authentifizieren.

Damit Commits nicht meine echte Account-Mail zeigen, ist lokal die GitHub-Noreply-Adresse konfiguriert: 

git config --global user.name "new-waves"
git config --global user.email "100098860+new-waves@users.noreply.github.com"

Der VPS bekommt nur Leserechte

Auf dem VPS wurde ebenfalls ein SSH-Key erzeugt. Dieser Key ist aber kein normaler GitHub-Account-Key, sondern ein Deploy Key direkt im Repository newwaves.dev. Er hat nur Leserechte.

Das passt zur Rolle des Servers: Der VPS soll Code von GitHub ziehen können, aber nicht selbst Änderungen zurück nach GitHub pushen.

Wechsel des Live-Ordners

Vor dem Wechsel wurde der bestehende Live-Ordner auf dem VPS gesichert. Danach wurde das GitHub-Repository zuerst in einen Testordner geklont. So konnte ich vergleichen, ob der Git-Stand wirklich zum bisherigen Live-Stand passt. 

sudo cp -a /var/www/newwaves.dev /var/www/newwaves.dev.backup-2026-04-30
sudo mkdir /var/www/newwaves.dev-git-test
sudo chown user0:user0 /var/www/newwaves.dev-git-test
git clone git@github.com:new-waves/newwaves.dev.git /var/www/newwaves.dev-git-test
diff -qr /var/www/newwaves.dev /var/www/newwaves.dev-git-test

Beim Vergleich waren einige Unterschiede erwartet: Im Git-Clone gibt es z. B. den Ordner .git und die Datei .gitignore. Außerdem versioniert Git keine leeren Ordner. Wenn ein leerer Ordner später trotzdem erhalten bleiben soll, braucht er eine Platzhalterdatei wie .gitkeep.

Danach wurde der bisherige SFTP-Live-Ordner nicht gelöscht, sondern umbenannt. Der getestete Git-Ordner bekam anschließend den Live-Pfad. Dadurch musste die Webserver-Konfiguration nicht angepasst werden, weil /var/www/newwaves.dev weiterhin derselbe Pfad blieb. 

sudo mv /var/www/newwaves.dev /var/www/newwaves.dev.pre-git-sftp
sudo mv /var/www/newwaves.dev-git-test /var/www/newwaves.dev
sudo chown -R user0:user0 /var/www/newwaves.dev

Normaler Ablauf ab jetzt

Seitdem ist der Ablauf klar getrennt. Auf der Workstation wird gearbeitet und gepusht. Auf dem VPS wird nur noch gezogen. 

cd "C:\Users\user0\Desktop\Projekte\newwaves.dev"
git status
git add .
git commit -m "Beschreibung der Änderung"
git push
cd /var/www/newwaves.dev
git pull

Meine Regeln für diesen Workflow

  • Vor lokalen Arbeiten zuerst git pull, damit der Stand aktuell ist.
  • Keine Secrets, Tokens oder privaten Konfigurationsdateien committen.
  • Den VPS nicht mehr per SFTP überschreiben, solange Git der führende Deploy-Weg ist.
  • Website-Dateien nicht direkt auf dem VPS bearbeiten.
  • Wenn git pull Konflikte meldet, stoppen und erst die Ursache klären.

Der große Gewinn ist nicht nur Bequemlichkeit, sondern Nachvollziehbarkeit. GitHub ist jetzt die zentrale Quelle, der VPS kann reproduzierbar aktualisiert werden, und alte SFTP-Stände bleiben als Backup erhalten. Aus manuellem Datei-Upload wurde ein kleiner, aber brauchbarer Deploy-Workflow.