# 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). ```bash 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`](../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 ```bash 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`](../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`](07_qgis_tests_plan.md) und braucht einen Runner mit Docker. ## 7. Team informieren - [ ] Link zum Repository und zur [`README.md`](../../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`](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/`.