Git Control Tower
Massive Workspace-Sicht über alle gefundenen Git-Repositories mit Cleanliness, Drift, Milestone-Tags und Push-Readiness.
Schnell-Runbook: Git Operations Runbook (1-Seiten-SOP)
Repository Radar
| Repo | Branch | Status | Changes | Sync | Remote | HEAD |
|---|
Selected Repository
Klicke oben auf ein Repository, um Details zu sehen.
Milestone Tags On HEAD
| Repo | Tag | Commit |
|---|
Cleanup Queue (Safe)
| Repo | Action |
|---|
Praxis: Git-Bedienung fuer IIO (Classic + Agent Support)
Empfohlene Default-Strategie: immer Branch fuer Arbeit, Tag nur fuer Ruecksprungpunkte. Das liefert schnelle Iteration und sauberen Rollback.
1) Entscheidung Branch vs Tag
| Frage | Empfehlung | Warum |
|---|---|---|
| Aktiv entwickeln / bereinigen? | Branch | Isolation fuer WIP, saubere Reviews und PRs. |
| Stabilen Zwischenstand markieren? | Tag | Schneller Ruecksprung auf bekannten Zustand. |
| Beides noetig? | Ja: Branch + Tag | Branch fuer Arbeit, Tag vor riskanten Schritten als Safety-Net. |
2) Empfohlener Arbeitsablauf vor Low-Level-Bereinigung
- Arbeitsbaum pruefen: git status --short.
- Stabilen Punkt taggen (optional, aber empfohlen): git tag -a pre-cleanup-YYYYMMDD -m "before low-level cleanup".
- Feature-Branch starten: git switch -c feat/cleanup-i18n-pass.
- Zuerst Low-Level-Struktur bereinigen (keine Sprachmischung pro Artefakt).
- Danach Uebersetzungs-/Sprachpass als separater Commit.
- Review, Merge, optional Release-Tag setzen.
3) Sprach-/Uebersetzungs-Flow (AGT/DE/EN sauber halten)
Reihenfolge
- 1. Fachinhalt stabilisieren (ohne Stilmischung).
- 2. Zielkanal festlegen: AGT, DE oder EN.
- 3. Uebersetzungen erst nach Struktur-Review ziehen.
- 4. Jede Sprache als eigener, reviewbarer Commit.
Do / Don't
- Do: Eine Sprache pro Artefakt.
- Do: Source-of-truth klar markieren.
- Don't: Sprach- und Strukturumbau in einem Commit vermischen.
- Don't: Unreviewte Agent-Outputs direkt publizieren.
4) Classic-Bedienung vs Bedienung mit Coding-Agent
| Modus | Wer treibt | Git-Regel | Gate |
|---|---|---|---|
| Classic (ohne Agent) | Human Operator | Branch-basiert, kleine Commits, Review vor Merge | Normales Peer-/Owner-Review |
| Assisted (mit Coding-Agent) | Human + Agent (Proposal-Modus) | Eigener Branch pro Agent-Lauf; Agent produziert Vorschlaege, Human merged | HITL zwingend fuer state-aendernde Schritte |
5) Klare Abgrenzung fuer Client-Betrieb (ohne/mit Agent)
In IIO sind Human und Agent kein ontologischer Bruch, aber in der Bedienung gibt es klare Kommunikationsmodi. Fuer Kundenbetrieb ist die operative Abgrenzung wichtig:
- Client ohne Agent: nur klassische Git-Rails, menschliche Ausfuehrung, menschliches Review.
- Client mit Agent: Agent darf analysieren/vorschlagen/patchen im Branch, aber keine ungepruefte Direktfreigabe.
- Immer gleich: GO/BLOCK/ESCALATE und nachvollziehbarer Audit-Trail.
6) Minimales Command-Set fuer den Alltag
git fetch --all --prune git status --short git switch -c feat/<topic> # arbeiten, dann git add -A git commit -m "feat: <scope>" git push -u origin feat/<topic> # optionaler Sicherheitsanker git tag -a checkpoint-<YYYYMMDD-HHMM> -m "checkpoint before merge" git push origin --tags
7) Praktische Empfehlung fuer eure aktuelle Frage
- Ja, zuerst Low-Level bereinigen, dann Uebersetzungen einbringen.
- Vor dem Cleanup einen Tag auf den aktuellen stabilen Stand setzen.
- Die eigentliche Arbeit konsequent auf Branches durchfuehren.
- Client-Betrieb als zwei Bedienprofile dokumentieren: classic und assisted.