Two sources of truth that disagree
The board says task 442 is done. The repository says the last commit touching it was three weeks ago and its pull request is still open.
Which one is right? The repository. It's always the repository.
The reason is simple: updating the board is something people have to remember to do, while committing is part of the work itself. Any workflow that leans on human memory drifts away from reality over time — not because anyone is careless, but because extra work is always the lowest priority.
The fix isn't reminding the team to update the board. It's deriving the update from the work.
The convention: TASK-<id> in the commit message
The whole pattern fits in one line. Put the task ID in the commit message:
TASK-442 fix memory leak in the report generator
The Git webhook sees it and attaches the commit to task 442. No manual step, no opening a browser.
One commit, several tasks. If a change touches multiple tasks, list them all in the same message:
TASK-12 TASK-34 fix shared bug in the auth layer
Branch names as a backstop. If forgetting the commit message is a persistent problem, add a branch naming convention:
task/442-memory-leak-report-generator
This helps because you write the branch name once and the commit message ten times.
If the commit already exists. You don't need to rewrite history — the attach_commit tool links a commit hash to one or more tasks:
"Attach commit a3f9c21 to tasks 12 and 34."
What becomes automatic
Once linked, several things happen without your involvement.
Tasks get a code history. The task page shows the related commits, branches, and pull requests. Reviewers stop asking "where's the code for this?"
Status can advance on its own. You can configure the first commit on a task to move it from Todo to In Progress. It sounds minor, but it's the single step that gets skipped most often.
Delivery reporting becomes real. Instead of asking "how far along are we?" and getting a feeling, you see which tasks have code, which pull requests are still open, and which have been untouched for weeks.
Engineering reviews get grounded. When project status comes from the repository rather than a slide, the discussion is about reality.
Setting it up
1. Connect the repository. In project settings, go to the Git integration section and connect your GitHub or GitLab repo. If an org admin has shared the connection, you just pick the repository.
2. Verify the webhook. After connecting, push a test commit with TASK-<id> and check that it appears on the task. If it doesn't, the webhook usually isn't registered in the repo settings.
3. Write the convention in the wiki. One short page: commit message format, branch name format, and when a task goes up for review. A new hire figures it out without asking.
4. Watch for it in code review. For two weeks, check in review that the task ID is present. After that it becomes habit.
A note on infinite loops
If the project tool writes to Git on every task change and Git writes to the task on every event, you build a feedback loop that feeds itself.
WKFGo tags the events it generates itself and ignores them on the way back. If you're writing a custom integration, account for this — it's the classic bug in this kind of connection, and it usually gets discovered when someone receives a hundred notifications in ten seconds.
Common mistakes
Writing the number without the prefix. 442: fix leak isn't recognized; the pattern looks for TASK-442. A vague convention is worse than no convention.
Connecting without a written convention. Installing the integration is the easy part; writing down how the team uses it is the work.
Expecting the link to replace review. Having a commit means work started, not that it was done correctly.
Forgetting old branches. Tasks completed before you connected won't have linked code. That's fine — fix it going forward, don't rewrite the past.
FAQ
What if the team doesn't write the task ID?
That task won't have linked code and will show up empty in reports. The branch convention is a decent backstop, but ultimately this is a team habit, not a technical feature.
Does it work with private repositories?
Yes. The connection uses your access token and has exactly the permissions you granted it.
What about pull requests?
If the task ID is in the PR title or description, it links too. Useful for reviewing what's still awaiting review.
What if one task has ten commits?
They all link. On large tasks that's a signal in itself: it probably should have been broken up.
Summary
Linking Git to tasks isn't a complex feature — it's a one-line convention that moves status updates out of people's memory and into the work itself.
Start with one project, check adherence in code review for two weeks, then look at the delivery report. You'll see the difference.