Git + Gitea + Claude – Setup-Guide

✅ Voraussetzungen

Bevor es losgeht, stelle sicher dass folgendes vorhanden ist:

Git auf dem PC installiert → git --version im Terminal testen
Gitea läuft auf der Synology und ist erreichbar unter git.cloudyday.ddnss.de
Ein Gitea-Konto ist angelegt
Claude Code ist installiert (claude im Terminal verfügbar)

Tipp: Git für Windows gibt es auf git-scm.com. Nach der Installation Terminal neu starten.

1 Repository auf Gitea anlegen

Hinweis: Dieser Schritt kann übersprungen werden, wenn du dich mit einem bereits bestehenden Repository verbinden möchtest. In dem Fall die URL des vorhandenen Repos direkt in Schritt 3 verwenden.

Im Browser auf die Gitea-Oberfläche gehen und ein neues Repository erstellen:

Oben rechts auf + → Neues Repository
Name vergeben, z.B. mein-projekt
Optional: Beschreibung hinzufügen
„Repository initialisieren" NICHT anhaken — das machen wir lokal
Auf Repository erstellen klicken

Gitea zeigt danach die Repository-URL an. Diese URL wird in Schritt 3 gebraucht.

URL-Format: https://git.cloudyday.ddnss.de/benutzername/mein-projekt.git

2 Lokales Verzeichnis vorbereiten

Es gibt zwei Wege — je nachdem ob das Repo neu oder bereits vorhanden ist:

Variante A – Neues leeres Verzeichnis

Terminal

# In das Projektverzeichnis wechseln (oder neu anlegen)
cd C:\Users\dein-name\Desktop\mein-projekt

# Git-Repository initialisieren
git init

Nach git init wird ein versteckter .git-Ordner angelegt – ab jetzt ist das Verzeichnis ein Git-Repository.

Variante B – Bestehendes Repo direkt klonen (empfohlen wenn das Repo bereits Inhalt hat)⚡ Test für Marcus

Terminal

git clone https://git.cloudyday.ddnss.de/kai/git-test.git

git clone erstellt automatisch einen neuen Ordner, lädt alle Dateien herunter und setzt den Remote. Schritte 3–5 können danach übersprungen werden.

Variante C – Vorhandene lokale Daten in leeres Gitea-Repo importieren

Du hast Daten bereits lokal in einem Verzeichnis und das Repository auf Gitea ist noch leer? Dann dieses Verzeichnis als Git-Projekt initialisieren, committen und anschließend mit Gitea verknüpfen:

Schritt 1 – Git initialisieren & ersten Commit erstellen

# Git im aktuellen Ordner starten
git init

# Alle vorhandenen Dateien für den ersten Commit vormerken
git add .

# Den ersten Stand lokal speichern
git commit -m "Initialer Import meiner Daten"

Schritt 2 – Gitea-URL als Remote hinzufügen

git remote add origin https://git.cloudyday.ddnss.de/Kai/DEIN_REPO_NAME.git

Wichtig: Die URL findest du im leeren Repository auf Gitea direkt nach dem Anlegen angezeigt.

Schritt 3 – Daten hochladen

git push -u origin master

„Dubious ownership"-Fehler? Falls Git beim Arbeiten auf einem Netzlaufwerk meckert, einmalig ausführen:

git config --global --add safe.directory "%(prefix)%/$(pwd)"

Danach den Push erneut versuchen.

3 Gitea als Remote verbinden

Das lokale Repository mit dem Gitea-Repository auf der Synology verknüpfen:

Terminal

git remote add origin https://git.cloudyday.ddnss.de/kai/git-test.git

Hinweis: Bei einem anderen Repository ändert sich nur der letzte Teil der URL, z.B. …/kai/beki-test.git

Prüfen ob die Verbindung gesetzt wurde:

Terminal

git remote -v

Ausgabe sollte so aussehen:

Ausgabe
origin  https://git.cloudyday.ddnss.de/kai/git-test.git (fetch)
origin  https://git.cloudyday.ddnss.de/kai/git-test.git (push)

4 Erste Datei erstellen und committen

Hinweis: Dieses Repository (git-test) hat bereits Inhalt — Schritt 4 kann übersprungen werden. Direkt weiter mit Schritt 5.

Eine Datei anlegen, stagen und den ersten Commit erstellen:

Terminal

# Alle Dateien zum Staging-Bereich hinzufügen
git add .

# Status prüfen – zeigt was committet wird
git status

# Commit erstellen
git commit -m "Erster Commit"

Hinweis: Beim allerersten Commit fragt Git nach Name und E-Mail. Einmalig setzen mit:

git config --global user.name "Dein Name"
git config --global user.email "email@beispiel.de"

5 Pullen und pushen

Wenn das Repository bereits Inhalt hat, zuerst den aktuellen Stand herunterladen:

Terminal – erst pullen

git pull origin master

Danach eigene Änderungen hochladen:

Terminal – dann pushen

git push -u origin master

Git fragt beim ersten Mal nach Benutzername und Passwort des Gitea-Kontos. Danach reicht für alle weiteren Pushes:

Terminal (bei weiteren Pushes)

git push

-u origin master setzt den Standard-Remote für diesen Branch – danach genügt git push ohne weitere Argumente.

Passwort nicht jedes Mal eingeben — einmalig speichern mit:

Terminal

git config --global credential.helper store

Nach dem nächsten Push mit Passwort wird es dauerhaft gespeichert. Gilt für alle Repositories auf diesem PC.

6 Claude Code einsetzen

Claude Code im Projektverzeichnis starten:

Terminal

cd C:\Users\dein-name\Desktop\mein-projekt
claude

Claude liest das gesamte Verzeichnis und kann direkt loslegen. Beispiele was man einfach per Chat erledigen kann:

„Erstelle eine index.html mit einem Dark-Mode-Toggle"
„Schreibe ein Node.js-Backend mit SQLite für ein Gästebuch"
„Committe alle Änderungen mit einer passenden Message und pushe"
„Erkläre mir was dieser Merge-Konflikt bedeutet und löse ihn"
„Baue einen Docker-Compose-Stack für nginx + Backend auf"
„Was hat sich seit dem letzten Commit geändert?"

Claude kann auch Git-Befehle direkt ausführen — einfach im Chat eingeben:

Im Claude-Chat

# ! vor dem Befehl leitet ihn ans Terminal weiter
! git status
! git log --oneline
! git pull

Tipp: Claude merkt sich den Kontext der gesamten Unterhaltung – man kann einfach in natürlicher Sprache weitermachen: „jetzt pushen", „füge noch einen Footer hinzu", „was könnte man noch verbessern?"

🙈 .gitignore – Dateien ausschließen

Manche Dateien sollen nicht ins Repository — z.B. Passwörter, lokale Konfigurationen oder der node_modules-Ordner. Dafür gibt es die .gitignore-Datei im Projektverzeichnis.

.gitignore – Beispiel

# Node.js Abhängigkeiten
node_modules/

# Umgebungsvariablen & Passwörter
.env
*.env

# Betriebssystem-Dateien
.DS_Store
Thumbs.db

# Editor-Einstellungen
.vscode/
.idea/

Die Datei einfach im Projektverzeichnis anlegen — Git ignoriert dann alles was darin steht automatisch.

Tipp: Claude kann eine passende .gitignore für das jeweilige Projekt generieren: „Erstelle eine .gitignore für ein Node.js-Projekt"

🌿 Branches – Parallel entwickeln

Ein Branch ist eine eigene Entwicklungslinie — ideal um neue Features auszuprobieren ohne den Hauptstand zu gefährden.

Terminal

# Neuen Branch anlegen und direkt wechseln
git checkout -b mein-feature

# Änderungen committen (wie gewohnt)
git add .
git commit -m "Feature XY hinzugefügt"

# Branch auf Gitea pushen
git push -u origin mein-feature

# Zurück zum Hauptbranch wechseln
git checkout master

# Branch einmergen
git merge mein-feature

Aktuellen Branch anzeigen:

Terminal

git branch

Faustregel: Auf master läuft immer der stabile Stand. Neue Features, Experimente oder Bugfixes kommen in eigene Branches.

🚀 Deployment auf der Synology

Nach jedem Push vom PC muss auf der Synology git pull ausgeführt werden damit die Änderungen live gehen. Das läuft über SSH:

SSH auf der Synology

# Per SSH verbinden
ssh benutzer@synology-ip

# In das Projektverzeichnis wechseln
cd /volume1/web/git-test

# Änderungen holen
git pull

# Falls Docker-Container beteiligt sind, neu starten
docker compose up -d --build

SSH aktivieren: Synology DSM → Systemsteuerung → Terminal & SNMP → SSH-Dienst aktivieren

Typischer Workflow:

Lokal mit Claude arbeiten und Änderungen machen
git push vom PC
Per SSH auf der Synology git pull ausführen
Fertig — Änderungen sind live

📋 Wichtige Git-Befehle auf einen Blick

git init	Neues Git-Repository im aktuellen Verzeichnis anlegen
git status	Zeigt geänderte, neue und bereits gestagte Dateien an
git add .	Alle Änderungen zum nächsten Commit vormerken (stagen)
git add <datei>	Nur eine bestimmte Datei stagen
git commit -m "…"	Gestagete Änderungen als Snapshot speichern
git push	Lokale Commits auf Gitea hochladen
git pull	Änderungen von Gitea herunterladen und einmergen
git log --oneline	Kompakte Übersicht aller bisherigen Commits
git diff	Zeigt alle nicht-gestagte Änderungen im Detail
git checkout -b <name>	Neuen Branch anlegen und direkt wechseln
git remote add origin <url>	Remote-Repository verknüpfen
git clone <url>	Vorhandenes Repository herunterladen

Alle Befehle werden im Terminal im Projektverzeichnis ausgeführt.

🔁 Deploy-Agent in ein anderes Projekt übertragen

Der deploy-agent aus diesem Repo kann in jedes andere Projekt übernommen werden. Damit Claude ihn direkt anpassen kann, einfach folgende Infos mitgeben:

Projektname / Repo	Wie heißt das Ziel-Repository auf Gitea?
Verzeichnis (Synology)	Wo liegt das Projekt auf der Synology? z.B. /volume1/web/mein-projekt
Port	Auf welchem Port soll der deploy-agent laufen? (aktuell 3047 — darf nicht doppelt vergeben sein)
Container-Namen	Welche Container sollen nach dem Push neu gebaut werden? (aus dem compose.yaml des Projekts)

Beispiel-Nachricht an Claude:

Vorlage

Ich möchte den deploy-agent in mein Projekt "mein-projekt" übertragen.
Verzeichnis auf der Synology: /volume1/web/mein-projekt
Port: 3048
Container die neu gebaut werden sollen: mein-projekt-backend, mein-projekt-static

Wie funktioniert der Ablauf? Du pushst vom PC → Gitea feuert einen Webhook → der deploy-agent empfängt ihn, macht git pull und startet die Docker-Container neu → Änderungen sind sofort live.

Webhook in Gitea einrichten

Im Gitea-Repository unter Einstellungen → Webhooks → Webhook hinzufügen → Gitea folgende Werte eintragen:

Ziel-URL	http://<synology-ip>:<port>/deploy?token=<WEBHOOK_SECRET> z.B. http://192.168.1.100:3047/deploy?token=meinGeheimnis
HTTP-Methode	POST
Content-Type	application/json
Auslöser	Push-Events
Aktiv	✓ Haken setzen

WEBHOOK_SECRET ist das Passwort das in der .env-Datei auf der Synology gesetzt ist — steht auch in der compose.yaml unter environment. Es verhindert dass fremde den Deploy-Endpoint aufrufen können.

Nach dem Speichern kann der Webhook direkt mit „Testen" geprüft werden — der deploy-agent sollte mit 200 OK antworten.

⚠️ Typische Fehler & Lösungen

„Your local changes would be overwritten by merge"

Lösung

# Lokale Änderungen an einer Datei verwerfen
git checkout <dateiname>

# Dann erneut pullen
git pull

„Please tell me who you are" (kein Name/E-Mail gesetzt)

Lösung

git config --global user.name "Dein Name"
git config --global user.email "email@beispiel.de"

„rejected – non-fast-forward" beim Push

Lösung

# Erst pullen, dann pushen
git pull
git push