Version Control (Git) und Deployment (FTP / SSH)

Erste Schritte: Version Control (Git) und Deployment (FTP / SSH)

Mit Git verfolgst du Änderungen am Code, arbeitest im Team
und kannst jederzeit zum funktionierenden Stand zurückrollen.
Für das Online‑Stellen (Deployment) nutzt du einfache FTP‑Uploads oder
(besser) SSH‑basierte Prozesse wie git pull auf dem Server.
Dieses Tutorial zeigt den typischen Workflow – alle Befehle stehen in <pre>‑Blöcken.

1. Git Basics – Repository anlegen

# im Projektordner
git init                # leeres Repo erzeugen
git add .               # alle Dateien zur Staging‑Area
git commit -m "Init"    # ersten Commit erstellen

.gitignore (im Wurzelverzeichnis) verhindert, dass temporäre oder sensible Dateien eingecheckt werden: 

/vendor/
.env
*.log
.idea/

2. Remote Repository (GitHub / GitLab)

# neues Repo auf GitHub anlegen → URL: git@github.com:ich/projekt.git
git remote add origin git@github.com:ich/projekt.git
git branch -M main
git push -u origin main         # erster Push
  • origin – Standard‑Alias für den Remote‑Server.
  • -u setzt Upstream, danach reicht git push.

3. Branching & Merge

git checkout -b feature/login   # neuen Branch erstellen
# … Code ändern …
git add .
git commit -m "Login‑Maske fertig"
git push origin feature/login   # Branch hochladen

# Merge‑Request / Pull‑Request auf GitHub erledigen
git checkout main
git pull          # nach erfolgreichem Merge Remote → lokal

4. Deployment – Variante A : FTP (Schnell aber manuell)

  1. Baue lokale Produktions‑Assets (z. B. npm run prod).
  2. Lade mit einem FTP‑Programm (FileZilla, Cyberduck)
    nur geänderte Dateien auf den Webspace.
  3. Nachteil – menschliche Fehler möglich, kein Rollback.

5. Deployment – Variante B : SSH mit git pull (Recommended)

# Einmalig auf dem Server
ssh user@server
cd /var/www/projekt
git clone git@github.com:ich/projekt.git .
composer install --no-dev --optimize-autoloader
exit

Ab dann genügt bei jedem Release: 

ssh user@server "cd /var/www/projekt && git pull && composer install --no-dev --optimize-autoloader && php artisan migrate --force"
  • Alle Dateien stammen direkt aus Git – keine Inkonsistenzen.
  • Mit Tags / Branches kannst du gezielt Versionen deployen (git checkout v1.2.0).

6. SSH‑Keys für Passwort­lose Logins

# lokal
ssh-keygen -t ed25519 -C "deploy"
cat ~/.ssh/id_ed25519.pub

Public Key in ~/.ssh/authorized_keys auf dem Server einfügen.
Jetzt laufen ssh und git pull ohne Passwortabfrage.

7. Automatisiertes Deployment (CI/CD)

Plattformen wie GitHub Actions, GitLab CI oder Deployer‐PHP erledigen Schritte nach jedem Push:

# .github/workflows/deploy.yml (Kurzbeispiel)
name: Deploy
on:
  push:
    branches: [ main ]
jobs:
  prod:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Sync via rsync over SSH
        run: rsync -avz --delete ./ user@server:/var/www/projekt
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_KEY }}

8. Datenbank‑Migrations & Backups

  • Vor jedem Deployment Backup (mysqldump …) automatisieren.
  • Nutze Framework‑Migrations (Laravel artisan migrate, Symfony doctrine:migrations)
    und setze –force im Produktionsskript.

9. Rollback‑Strategien

# auf dem Server zum vorherigen Tag
git checkout v1.1.0
composer install --no-dev --optimize-autoloader

Oder verwende Blue‑Green‑Deploy (zweiter Ordner + Symlink‑Switch).

10. Zusammenfassung

  • Git – lokales Branching, Remote auf GitHub/GitLab, nachvollziehbare Historie.
  • Für kleine Seiten reicht FTP; besser ist SSH + git pull.
  • Automatisierte CI/CD‑Pipelines vermeiden manuelle Fehler.
  • Sicher deployen = Commit, Push, Pull – Code und History bleiben identisch.

Fazit

Mit Git behältst du jede Änderung unter Kontrolle und kannst Features in Branches entwickeln,
während Deployment per SSH + git pull reproduzierbar und rückrollbar ist.
Automatisierte Workflows (CI/CD) heben den Prozess auf Knopfdruck – so bleibt deine PHP‑Site
up‑to‑date, stabil und sicher online.