Doku / Git & Issues
Git & Issues
Trag an einem Projekt die Repository-Adresse ein – VibeWorks zeigt dann Commits, CI-Status und Abhängigkeiten. Mit einer Git-Verbindung werden Aufgaben außerdem zu Issues.
Git-Verbindung
Unter Mein Konto → Git-Verbindungen legst du einmal ein Token an; es gilt für alle deine Projekte auf diesem Server. Selbst gehostetes GitLab und Gitea/Forgejo gehen genauso.
| Anbieter | Token |
|---|---|
| GitHub | Klassisches Token mit repo, admin:repo_hook (Webhooks) und workflow (Repo-Check) |
| GitLab | Persönliches Zugangstoken mit api |
| Gitea / Forgejo | Token mit repository: lesen und issue: lesen und schreiben |
Tokens werden beim Speichern geprüft, mit AES-256-GCM verschlüsselt und nie wieder vollständig angezeigt. Öffentliche Repositories ohne Issue-Spiegelung brauchen gar kein Token.
Repositories automatisch verbinden
Nach dem Verbinden legt VibeWorks für jedes eigene Repository ein Projekt an – danach alle 30 Minuten auch für neue. Forks und archivierte bleiben draußen, schon verknüpfte werden wiedererkannt, und ein gelöschtes Projekt kommt nicht wieder. Pro Verbindung lässt sich das abschalten oder mit Jetzt importieren sofort anstoßen.
Beliebiger Git-Server
Jeder Git-Server, der per https (oder http) erreichbar ist, geht auch – ohne API. Als Verbindung Beliebiger Git-Server wählen, Serveradresse eintragen und den Zugang als benutzer:token hinterlegen. VibeWorks holt Commits und die Paketdateien dann direkt per git; Issues, CI und Webhooks gibt es dort nicht. Repositories trägst du hier am Projekt ein. Unbekannte Server ohne GitHub-, GitLab- oder Gitea-API behandelt VibeWorks automatisch so.
Fehler
Scheitert ein Abgleich oder Import, steht der Grund bei der Verbindung, als rotes Git-Symbol auf der Projektkarte und oben auf dem Dashboard. Ab dem dritten Fehlschlag in Folge (beim Import ab dem zweiten) kommt einmal eine Benachrichtigung „Git-Abgleich scheitert“ – bis es wieder klappt.
Aufgaben ↔ Issues
Jede Aufgabe wird ein Issue, der Status wandert in beide Richtungen:
| Spalte in VibeWorks | Issue im Repository |
|---|---|
| Offen | offen |
| In Arbeit | offen, Label in Arbeit |
| Blockiert | offen, Label blockiert |
| Erledigt | geschlossen |
Ein Commit mit Fixes #12 schließt das Issue – beim nächsten Abgleich springt die Aufgabe auf „Erledigt“. Der Server gleicht alle 5 Minuten ab, mit einem Webhook sofort.
Webhooks
Projektseite → Git & Updates → Zugang → Webhook einrichten. Danach kommen Pushes, Issues und CI-Ergebnisse ohne Verzögerung an.
CI-Status
GitHub Actions, GitLab-Pipelines und Gitea-Actions des Hauptzweigs erscheinen als Punkt auf der Projektkarte und im Git-Bereich. Schlägt die CI fehl, gibt es auf Wunsch eine Benachrichtigung.
Abhängigkeiten-Check
VibeWorks liest die Paketdateien im Repository – package.json (npm), requirements.txt und pyproject.toml (PyPI), Cargo.toml, go.mod, composer.json und pom.xml –, vergleicht jede Abhängigkeit einmal am Tag mit der neuesten Version (Major, Minor, Patch) und fragt OSV.dev nach bekannten Lücken. Der Zweig ist wählbar; „Jetzt prüfen“ geht jederzeit.
Was dabei markiert ist, steht sofort als Aufgabe im Board: eine für Sicherheitslücken, eine für Updates, jeweils mit der Liste der Pakete. Die Liste hält sich selbst aktuell, und ist nichts mehr markiert, ist die Aufgabe erledigt. Hakst du sie selbst ab, bleibt sie zu – bis ein neues Paket dazukommt.
Repo-Check
Für GitHub-Repositories legt VibeWorks die Datei .github/workflows/vibeworks-check.yml an – ein kostenloser Workflow ohne KI, der montags und auf Jetzt prüfen läuft: Geheimnisse im Verlauf (Gitleaks), bekannte Sicherheitslücken in allen Abhängigkeiten (OSV-Scanner), Fehlermuster (Semgrep), je Sprache Bandit, ShellCheck, Hadolint, actionlint und fallow (toter Code in JS/TS) sowie TODO/FIXME-Kommentare. VibeWorks holt den Bericht selbst ab und verlinkt jede Fundstelle.
- Das Token braucht dafür das Recht
workflow(der Link in VibeWorks ist vorausgefüllt). - Der Workflow darf nur lesen, gibt sein Token nicht an die Prüfwerkzeuge weiter, und Gitleaks überträgt nie den Wert eines Geheimnisses – nur Datei, Zeile und Regel.
- Die Ergebnisse sehen nur Projektmitglieder, nie öffentliche Seiten oder das Portfolio.
- Ausschalten (Projektseite → Repo-Check) nimmt die Datei wieder aus dem Repository. Wer sie dort löscht, schaltet den Check ebenfalls ab; eine selbst angepasste Datei überschreibt VibeWorks nicht.
- Neue Geheimnisse oder Lücken melden sich auf Wunsch als Benachrichtigung und in den Wochen-Vorschlägen.
CI-Designer
Projektseite → CI-Pipeline (GitHub): Auslöser wählen (Push, Pull Request, Zeitplan, von Hand), Blöcke einfügen und verschieben – Node, npm-Skripte, fallow, Python/pytest, Go, Rust oder eigene Befehle, jeweils mit Bedingung. VibeWorks schlägt eine Pipeline aus den Dateien des Repositorys vor, schreibt sie als .github/workflows/vibeworks-ci.yml, startet sie und zeigt jeden Block live mit Ladesymbol, Haken oder Kreuz. Eine selbst geänderte Datei überschreibt VibeWorks nicht; das Token braucht das Recht workflow.
Lighthouse-Check
Projektseite → Lighthouse-Check → Einschalten (nur der Besitzer, braucht eine Live-Adresse): VibeWorks legt .github/workflows/vibeworks-lighthouse.yml an. Der Workflow prüft montags und auf Jetzt prüfen die Live-Seite mit Lighthouse (Leistung, Barrierefreiheit, Best Practices, SEO) und sucht mit lychee nach kaputten Links – nur mit Leserechten und ohne den Code auszuchecken. Fällt ein Wert um 10 Punkte oder mehr unter den besten bisherigen oder ist ein Link kaputt, erscheint eine Aufgabe, die sich selbst erledigt, sobald alles wieder passt. Ausschalten nimmt die Datei wieder heraus.
Eine Aufgabe für viele Projekte
Aufgaben → Für mehrere Projekte (oder in der Schnellerfassung „Alle mit Git“): dieselbe Aufgabe, etwa „Abhängigkeiten aktualisieren“, landet in jedem gewählten Projekt – samt Issue.