Bündelt die Neuentwicklung in AssigmentMonitorV2 (eigene Ports/DB), die Umstellung auf numerische Bewertungen, Meeting-Checklisten, KI-Tagging und die geplante Feedback-Kaskade — als Basis für Versionsverwaltung in Gitea. Co-authored-by: Cursor <cursoragent@cursor.com>
116 lines
3.3 KiB
Markdown
116 lines
3.3 KiB
Markdown
# Gitea — Repository-Setup (Assignment Monitor V2)
|
|
|
|
Dieses Projekt ist lokal ein Git-Repo auf Branch `main`. Für Gitea fehlt nur noch der Remote und der erste Push.
|
|
|
|
## Voraussetzungen
|
|
|
|
- Gitea-Zugang (Benutzerkonto auf dem Server)
|
|
- **HTTPS + Personal Access Token** (empfohhen unter Windows / Firmennetz) **oder** SSH-Key bei Gitea hinterlegt
|
|
- Keine Secrets im Repo: `.env` und `server/data/` sind in `.gitignore`
|
|
|
|
## 1. Repository in Gitea anlegen
|
|
|
|
1. In Gitea einloggen
|
|
2. **„+“ → New Repository** (oder Organisation wählen, dann „New Repository“)
|
|
3. Einstellungen:
|
|
- **Name:** `AssigmentMonitorV2` (oder gewünschter Name)
|
|
- **Private** (empfohlen — personenbezogene Trainingsdaten im Backup-Format)
|
|
- **Initialize repository:** alle Häkchen **aus** (kein README, keine .gitignore — existiert lokal schon)
|
|
4. Erstellen
|
|
|
|
Gitea zeigt danach die Push-URLs an, z. B.:
|
|
|
|
- HTTPS: `https://gitea.example.com/lars/AssigmentMonitorV2.git`
|
|
- SSH: `git@gitea.example.com:lars/AssigmentMonitorV2.git`
|
|
|
|
## 2. Remote hinzufügen (lokal)
|
|
|
|
HTTPS (empfohlen):
|
|
|
|
```powershell
|
|
cd C:\dev\AssigmentMonitorV2
|
|
git remote add origin https://gitea.example.com/<user>/AssigmentMonitorV2.git
|
|
git remote -v
|
|
```
|
|
|
|
SSH (Alternative):
|
|
|
|
```powershell
|
|
git remote add origin git@gitea.example.com:<user>/AssigmentMonitorV2.git
|
|
```
|
|
|
|
## 3. Authentifizierung
|
|
|
|
### HTTPS — Personal Access Token (empfohlen)
|
|
|
|
1. Gitea → **Settings → Applications → Generate New Token**
|
|
2. Scopes: mindestens **`write:repository`** (bzw. „repo“ je nach Gitea-Version)
|
|
3. Beim ersten `git push`:
|
|
- **Username:** Gitea-Benutzername
|
|
- **Password:** der Token (nicht das Login-Passwort)
|
|
|
|
Windows speichert Credentials oft über den Credential Manager (`credential.helper=manager`).
|
|
|
|
### SSH
|
|
|
|
1. Key erzeugen (falls noch keiner existiert):
|
|
|
|
```powershell
|
|
ssh-keygen -t ed25519 -C "lars.stommer@capgemini.com"
|
|
```
|
|
|
|
2. Öffentlichen Key (`~/.ssh/id_ed25519.pub`) in Gitea unter **Settings → SSH Keys** eintragen
|
|
3. Verbindung testen:
|
|
|
|
```powershell
|
|
ssh -T git@gitea.example.com
|
|
```
|
|
|
|
## 4. Ersten Push ausführen
|
|
|
|
```powershell
|
|
cd C:\dev\AssigmentMonitorV2
|
|
git push -u origin main
|
|
```
|
|
|
|
Falls Gitea standardmäßig `master` erwartet und leer ist, reicht obiger Befehl. Bei Konflikt mit vorgefertigtem Initial-Commit auf dem Server:
|
|
|
|
```powershell
|
|
git pull origin main --rebase
|
|
git push -u origin main
|
|
```
|
|
|
|
## 5. Täglicher Workflow
|
|
|
|
```powershell
|
|
git status
|
|
git add -A
|
|
git commit -m "kurze Beschreibung des Warums"
|
|
git push
|
|
```
|
|
|
|
Feature-Branches (optional):
|
|
|
|
```powershell
|
|
git checkout -b feature/feedback-kaskade-stufe-a
|
|
# … arbeiten …
|
|
git push -u origin feature/feedback-kaskade-stufe-a
|
|
```
|
|
|
|
In Gitea dann Pull Request / Merge Request erstellen.
|
|
|
|
## Datenschutz
|
|
|
|
- **Nicht committen:** `.env`, `server/data/*.sqlite3`, OpenRouter-API-Keys, Produktiv-Backups mit echten Personendaten
|
|
- **Private Repo** auf Gitea verwenden
|
|
- Backup-JSONs aus der App nur verschlüsselt/teambasiert teilen, nicht ins Repo legen
|
|
|
|
## Troubleshooting
|
|
|
|
| Problem | Lösung |
|
|
|---|---|
|
|
| `403` / `Authentication failed` | Token statt Passwort; Token-Scopes prüfen |
|
|
| `remote origin already exists` | `git remote set-url origin <neue-url>` |
|
|
| Große Dateien abgelehnt | Keine DB/Backups committen; ggf. Gitea-LFS nur wenn wirklich nötig |
|
|
| SSL-Zertifikat (interne CA) | Firmen-Root-Zertifikat in Windows/Git hinterlegen oder IT fragen |
|