Projektübersicht

Aufbau eines selbst gehosteten Git-Servers (Forgejo) mit automatischem Push Mirror zu GitHub, einheitlicher Namenskonvention und strukturiertem Workflow für SPS-, Embedded- und Hardware-Projekte.

1. Situation (Ausgangslage)

Für die Arbeit mit CODESYS (SPS-Programmierung), STM32CubeIDE (Embedded C) und KiCad (PCB-Design) fehlte eine zentrale Versionskontrolle. Projektdateien lagen lokal ohne Versionierung. Es gab keine einheitliche Struktur für Repositories, keine Commit-Konventionen und keinen einfachen Weg, Projekte bei Bedarf einem potenziellen Arbeitgeber oder Interviewer zugänglich zu machen.

2. Task (Zielsetzung)

• Eigener Git-Server: Versionskontrolle auf eigener Infrastruktur, unabhängig von Drittanbietern.
• Automatisches Mirroring: Jeder Push lokal spiegelt sich automatisch auf GitHub, ohne manuellen Aufwand.
• Einheitliche Struktur: Namenskonvention für Repositories, Commit-Prefixe, Projektvorlagen und Ordnerstruktur, damit jedes Projekt gleich aufgebaut ist.
• Interviewer-Zugriff: Eine schnelle Möglichkeit, ausgewählte Projekte für Arbeitgeber sichtbar zu machen.

3. Action (Umsetzung)

A. Forgejo als LXC-Container

Forgejo 10.0.1 auf einem Debian 12 LXC-Container installiert und konfiguriert:

• SQLite3 als Datenbank (ausreichend für Einzelnutzer), systemd-Service für Autostart.
• Authentifizierung über HTTPS mit Personal Access Token, Token im Passwort-Manager gespeichert.
• Tägliches Backup über Proxmox Backup Server auf die NAS.

B. Push Mirror zu GitHub

Für jedes Repository ein automatisches Push Mirror eingerichtet:

• Bei jedem git push an Forgejo wird der Stand automatisch an das entsprechende GitHub-Repository weitergeleitet.
• Authentifizierung über GitHub PAT (scope: repo).
• GitHub dient als öffentlich erreichbares Portfolio, Forgejo bleibt der primäre Arbeitsserver.

C. Konventionen und Vorlagen

Einen durchgängigen Standard für alle Projekte definiert:

• Namenskonvention: [Nummer]-[Board]_[Plattform]_[Kurzbeschreibung] (z.B. 01-BBB_CODESYS_hello-led).
• Commit-Prefixe: Phase X: für abgeschlossene Phasen, Fix: für Fehlerbehebungen, Docs: für Dokumentation.
• Projektstruktur: README.md auf Englisch mit Hardware, Lernzielen und Phasen-Übersicht. Jede Phase als eigene Datei unter docs/ mit Code, Erklärung und Lernpunkten.
• .gitignore-Vorlagen: Für CODESYS, STM32 und KiCad, damit temporäre Dateien und Kompilierungs-Artefakte nicht ins Repository gelangen.

D. Interviewer-Zugriff

Zwei Optionen vorbereitet, um Projekte bei Bewerbungsgesprächen zugänglich zu machen:

• Temporäres Umschalten auf Public in GitHub (nach dem Gespräch wieder Private).
• Einladung als Collaborator mit Read-Berechtigung.

4. Result (Ergebnis & Verifikation)

• Alle SPS-, Embedded- und Hardware-Projekte sind versioniert und zentral auf eigener Infrastruktur gespeichert.
• Jeder Push landet automatisch auf GitHub, ohne zusätzlichen Schritt.
• Neue Projekte können in wenigen Minuten nach dem gleichen Schema angelegt werden: Repository erstellen, Mirror einrichten, klonen, loslegen.
• Arbeitgeber oder Interviewer können innerhalb von Sekunden Zugriff auf ausgewählte Projekte erhalten.

Lessons Learned

• Eigener Server vs. nur GitHub: Ein selbst gehosteter Git-Server gibt volle Kontrolle über die Daten. GitHub ist der öffentliche Spiegel, nicht die Quelle.
• Konventionen von Anfang an: Einheitliche Namensgebung und Commit-Prefixe kosten am Anfang fünf Minuten Planung, sparen aber bei jedem weiteren Projekt Zeit und halten das Portfolio konsistent.
• Push Mirror statt manueller Sync: Manuelles Pushen an zwei Remotes wird vergessen. Automatisches Mirroring eliminiert diesen Fehler komplett.