Name the ticket. The code does the rest.

Linked the way Linear and Jira do it

Anything that names the key links itself: the branch name, the pull request title or description, commit messages. Keys ignore case, one pull request can carry several tickets, and one ticket can have pull requests in several repositories.

• Fixes, Closes and Resolves close the ticket on merge; Refs, Part of and Related to only link it.
• GitLab works on gitlab.com and self-managed; Bitbucket Cloud too.
• Copy branch name (B) and commit prefix (M) in the ticket header, so new work links from the first commit.

Reviews and checks on the ticket

Each pull request shows whether it is approved or has changes requested, and whether the checks of its head commit pass: GitHub checks, GitLab pipelines, Bitbucket builds. A push clears them until the new commit is checked.

Three switches per project

Move to In progress when a branch is pushed (off by default), to In review when a pull request opens, to Done when the last closing pull request is merged. Only closing links move tickets, and tickets that are done or cancelled stay as they are.

Deployments and feature flags

GitHub deployments, GitLab deployment events, Vercel and any CI that posts JSON report what shipped where. A ticket shows which environments its code reached and when, and its LaunchDarkly or other flags per environment. Releases list the done tickets that are not in production yet, so “merged” and “live” stop being confused.

• The rule template “Done when it reaches production” moves the ticket and tells the reporter.

Your old keys keep working

After an import from Jira, Linear or ClickUp, branches and commits that still use the old key link the imported ticket, and the links to code that tool knew come along.