Code bewegt das Ticket
Ticket nennen. Den Rest macht der Code.
Schreiben Sie den Key in einen Branch, einen Pull Request oder einen Commit, auf GitHub, GitLab oder Bitbucket. Das Ticket zeigt die Arbeit mit Reviews und Checks und bewegt sich selbst: In Arbeit, wenn der Branch gepusht wird, In Review, wenn der Pull Request aufgeht, Fertig, wenn der letzte gemergt ist, und Sie sehen, wann es in Produktion war.
et-12-duplicate-guard
moves to In progressBranch pushed · 3 commits#57 Fixes ET-12: Guard against duplicate bookings
moves to In reviewPull request openedApprovedChecks pass#57 merged into main
moves to DoneLast closing pull requestIn production · 2 hours ago
Vercel · staging yesterdayet-12-duplicate-guard · on in staging
Where its 31 tickets run
- production18/31
- staging26/31
- preview31/31
Done, not in production yet
- DoneET-9Absence calendar export
- DoneET-14Reminder before month close
Die Komponenten der App, mit Beispieldaten gerendert.
Verknüpft wie bei Linear und Jira
Alles, was den Key nennt, verknüpft sich selbst: der Branch-Name, Titel oder Beschreibung des Pull Requests, Commit-Nachrichten. Groß- und Kleinschreibung zählt nicht, ein Pull Request kann mehrere Tickets tragen, und ein Ticket kann Pull Requests in mehreren Repositories haben.
- Fixes, Closes und Resolves schließen das Ticket beim Merge; Refs, Part of und Related to verknüpfen nur.
- GitLab funktioniert auf gitlab.com und selbst betrieben, Bitbucket Cloud ebenso.
- Branch-Namen (B) und Commit-Präfix (M) in der Ticket-Kopfzeile kopieren, damit neue Arbeit ab dem ersten Commit verknüpft ist.
Reviews und Checks am Ticket
Jeder Pull Request zeigt, ob er freigegeben ist oder Änderungen angefragt sind, und ob die Checks seines letzten Commits bestehen: GitHub-Checks, GitLab-Pipelines, Bitbucket-Builds. Ein Push setzt sie zurück, bis der neue Commit geprüft ist.
Drei Schalter pro Projekt
Auf In Arbeit, wenn ein Branch gepusht wird (standardmäßig aus), auf In Review, wenn ein Pull Request aufgeht, auf Fertig, wenn der letzte schließende Pull Request gemergt ist. Nur schließende Verknüpfungen bewegen Tickets, und fertige oder abgebrochene Tickets bleiben, wie sie sind.
Deployments und Feature-Flags
GitHub-Deployments, GitLab-Deployment-Ereignisse, Vercel und jede CI, die JSON sendet, melden, was wo ausgeliefert wurde. Ein Ticket zeigt, welche Umgebungen sein Code wann erreicht hat, und seine Flags aus LaunchDarkly oder anderen Diensten je Umgebung. Releases nennen die fertigen Tickets, die noch nicht in Produktion sind, damit „gemergt“ und „live“ nicht mehr verwechselt werden.
- Die Regelvorlage „Fertig, wenn es in Produktion ist“ bewegt das Ticket und informiert die meldende Person.
Ihre alten Keys funktionieren weiter
Nach einem Import aus Jira, Linear oder ClickUp verknüpfen Branches und Commits, die noch den alten Key nennen, das importierte Ticket, und die Code-Verknüpfungen, die das Werkzeug kannte, kommen mit.
Fragen
Läuft unser Code über NEWWORK Projects?
Für die Verknüpfung lesen wir Namen, Titel, Status und Links von Branches, Pull Requests und Commits, nicht den Code. Nova und Brainstorm lesen Code nur aus den Repositories, die einem Projekt zugewiesen oder mit seinen Tickets verknüpft sind, in den Plänen, die sie enthalten.
Können Agenten Pull Requests ohne Verbindung zum Code-Host verknüpfen?
Ja. pm-pr-link per MCP funktioniert in jedem Plan. Mit verbundenem GitHub, GitLab oder Bitbucket werden Verknüpfungen und Statuswechsel automatisch.
Was ist mit Entwürfen?
Ein Pull Request im Entwurf verknüpft das Ticket und setzt es, wenn der erste Schalter an ist, auf In Arbeit. In den Review geht es, sobald er kein Entwurf mehr ist.
Geben Sie Ihrem nächsten Agenten einen Brief.
Kostenlos für bis zu 10 Personen, mit MCP für jeden Agenten. Keine Kreditkarte.