Projektwissen/docs/konzept/08_repo_einrichten.md

Repository „Projektwissen" auf Gitea einrichten

Prüfliste für den Maintainer. Stand 04.09.2026. Einmalig auszuführen; danach ist dieses Dokument nur noch Nachweis, was wie eingestellt wurde.

Alles hier ist Menschenarbeit. Ein KI-Agent kann die Texte vorbereiten, aber weder Repositories anlegen noch pushen noch Schutzregeln setzen (ADR 0007).

1. Repository anlegen

Gitea → Organisation AG_QGIS → Neues Repository.

Einstellung	Wert
Name	Projektwissen
Beschreibung	Gemeinsame Wissensbasis, Regeln und Werkzeuge der QGIS-Plugin-Entwicklung LNO Sachsen
Sichtbarkeit	öffentlich (wie die übrigen Repos der Organisation)
.gitignore, Lizenz, README	nicht anlegen lassen — bringt der erste Push mit
Issues	an
Wiki	aus — die Doku liegt versioniert im Repo (ADR-Begründung in docs/wissen/externe_dienste.md)
Standard-Branch	unstable – dort wird gearbeitet. Nicht stable (dann landet jeder Klon auf dem Releasestand) und nicht main (gibt es in diesem Modell nicht). Alle acht Code-Repos der Organisation stehen auf unstable; main haben nur Defaults, Linkliste und Repository, die kein Kanalmodell kennen.

2. Ersten Stand pushen

Der Ordner AG_QGIS/ ist bereits als Git-Repository vorbereitet, mit einem Commit, der genau die Dateien dieses Repositories enthält (die Plugin-Klone sind per .gitignore ausgenommen).

cd <…>/AG_QGIS
git status                    # erwartet: nichts Unversioniertes außer den Plugin-Klonen
git log --oneline             # erwartet: der vorbereitete erste Commit
git remote add origin https://entwicklung.flurneuordnung-sachsen.de/AG_QGIS/Projektwissen.git
git push -u origin unstable

Wir beginnen bewusst auf unstable, damit auch dieses Repository dem Kanal-Modell aus ../leitfaden/05_git_arbeitsweise.md folgt.

Vor dem Push prüfen:

• Autor des Commits stimmt. git log -1 --format='%an <%ae>' – erwartet wird die Adresse des Gitea-Kontos, weil Gitea Commits darüber dem Benutzer zuordnet. Stimmt sie nicht, vor dem Push korrigieren: bash git config user.name "Vorname Nachname" git config user.email "vorname.nachname@lfulg.sachsen.de" git commit --amend --reset-author --no-edit
• git status zeigt keine Plugin-Ordner (Plugin_SN_*, Repository, Linkliste, Defaults)
• entwuerfe/ ist nicht enthalten
• keine Zugangsdaten, keine Tokens, keine echten Verfahrensdaten
• python scripts/run_tests.py läuft
• python scripts/testkatalog.py --pruefen meldet „aktuell"

3. Branches anlegen

git switch -c testing unstable && git push -u origin testing
git switch -c stable  unstable && git push -u origin stable
git switch unstable

Danach in Gitea unter Einstellungen → Allgemein prüfen, dass der Standard-Branch weiterhin unstable ist — das Anlegen weiterer Branches ändert ihn zwar nicht, aber es kostet nichts, einmal hinzusehen.

4. Branch-Schutz setzen

Einstellungen → Branches (englisch: Settings → Branches), dort eine neue Branch-Schutzregel anlegen — je einmal für stable, testing und unstable:

Einstellung	Wert
Branch-Name	stable / testing / unstable
Push deaktivieren	an
Merge-Freigabe erforderlich	mindestens 1
Veraltete Freigaben verwerfen	an
Statusprüfungen erforderlich	erst aktivieren, wenn CI läuft (Abschnitt 6)

5. Dasselbe für die Plugin-Repositories

Dort fehlt bisher der stabile Kanal. Je Repo (Plugin_SN_Basis, Plugin_SN_Plan41, Plugin_SN_Verfahrensgebiet, Plugin_SN_Widmung, Plugin_SN_FLT, Plugin_SN_Topografie, Plugin_SN_Template):

• stable anlegen — aus testing, wo es das gibt, sonst aus unstable. Der Name muss exakt stable lauten, weil der Release-Workflow git checkout "$CHANNEL" ausführt (ADR 0007).
• Branch-Schutz für stable, testing, unstable wie in Abschnitt 4
• oldstable prüfen (Plugin_SN_Basis, Plugin_SN_Plan41): enthält er noch etwas Nötiges? Sonst löschen.
• Verwaiste Branches prüfen und löschen: feature/Drucklayout-überarbeiten, print_layout (Basis), bug/crash_on_exit (Plan41), alkis-nur-laden-stop, fix-fbschl-feldname (Verfahrensgebiet)

Erst danach funktioniert ein Release auf dem stabilen Kanal (Tag ohne Suffix).

6. Optional: Tests in CI

Vorlage: ../vorlagen/gitea_workflow_tests.yaml → als .gitea/workflows/tests.yaml in Plugin_SN_Basis, Plugin_SN_Plan41 und Plugin_SN_Verfahrensgebiet. Sie klont das Projektwissen und die Nachbar-Repos und führt den Baseline-Lauf aus.

Voraussetzung: ein Gitea-Runner mit dem Label alpine-latest (wie beim Release-Workflow). Läuft das, in Abschnitt 4 „Statusprüfungen erforderlich" aktivieren.

Der Ausbau zu Tests gegen echtes QGIS steht in 07_qgis_tests_plan.md und braucht einen Runner mit Docker.

7. Team informieren

• Link zum Repository und zur README.md verteilen
• Auf die Umstellung hinweisen: der Klon-Befehl heißt jetzt git clone .../Projektwissen.git AG_QGIS (Ordnername unverändert)
• Um Durchsicht der Entscheidungen 0006–0009 bitten; nach Zustimmung den Status aller ADR von „vorgeschlagen" auf „angenommen" setzen
• Jede Person trägt sich in docs/status/STATUS.md unter „Wer arbeitet woran" ein

8. Nach der Einrichtung zu klären

Diese Punkte liegen als Entwürfe bzw. offene Baustellen in docs/status/STATUS.md:

1. QGIS-Mindestversion. Steht auf 3.40, das seit Januar 2026 End of Life ist (07_qgis_tests_plan.md Abschnitt 2). Betrifft workspace.toml und alle .gitea/templates/metadata.template.
2. .vscode/ aus den Plugin-Repos entfernen. Liegt in vier Repos mit fest verdrahteten Pfaden eines einzelnen Arbeitsplatzes. Je ein kleiner Pull Request.
3. Release-Excludes ergänzen (Repository:hidden/workflows): AGENTS.md, CLAUDE.md, .agents/, .claude/, docs/, tests/, .vscode/.