Standardbranch des neuen Repos praezisiert: unstable
Gitea fragt den Standardbranch schon beim Anlegen ab, nicht erst beim ersten Push. Mit Begruendung und dem Abgleich zu den bestehenden Repos: acht Code-Repos stehen auf unstable, main nur die drei ohne Kanalmodell.
This commit is contained in:
@@ -18,7 +18,7 @@ Gitea → Organisation `AG_QGIS` → **Neues Repository**.
|
||||
| `.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 | wird beim ersten Push gesetzt |
|
||||
| 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
|
||||
|
||||
@@ -59,8 +59,8 @@ git switch -c stable unstable && git push -u origin stable
|
||||
git switch unstable
|
||||
```
|
||||
|
||||
Danach in Gitea unter **Einstellungen → Allgemein** den Standard-Branch auf `unstable` setzen — dort landet die
|
||||
tägliche Arbeit.
|
||||
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user