The branch that does too much
A pull request with 40 files changed, three unrelated bug fixes, and a half-finished refactor mixed in. The reviewer approves it anyway, because untangling it would take longer than the review itself.
That's what happens when branches aren't scoped to tasks. Work gets grouped by "whatever I was doing this week" instead of by the unit the team actually plans and reports on. The PR becomes unreviewable, the commit history becomes unreadable, and when something in that branch breaks production, nobody can say which of the three unrelated changes caused it.
Branch-per-task workflow is the fix, and it's a discipline, not a tool: one task gets exactly one branch, and that branch ships exactly what the task describes — nothing bundled in because it was convenient.
The naming convention
The branch name carries the task ID so the link is automatic instead of remembered:
task/442-fix-memory-leak-report-generator
WKFGo's Git webhook recognizes task/<id>-... and attaches every commit on that branch to task 442 without anyone writing TASK-442 by hand in each commit message — though doing that too doesn't hurt. (See linking commits to tasks for the commit-message half of this convention; the two work together.)
Creating the branch from the task itself removes the chance of a typo in the ID. Ask your MCP-connected editor:
"Create a branch for task 442."
The create_branch tool names it correctly and the link exists before the first commit.
Why one task really means one branch
Reviews get smaller and faster. A branch scoped to one task has a bounded diff. A reviewer can hold the whole change in their head, which is the difference between a real review and a rubber stamp.
Blame is precise. When production breaks, git bisect and the task history both point at one thing, not three tangled ones.
Status stops lying. If a branch mixes a shipped feature with an unfinished one, merging it either ships unfinished work or blocks finished work. Neither is a real option, so the branch sits open for weeks. One task per branch means a branch is either ready to merge or it isn't — no negotiation.
Reverting is safe. Reverting a branch that did one thing is a clean rollback. Reverting a branch that did four things means picking apart which parts to keep.
When a task is too big for one branch
Sometimes a task genuinely needs to land in stages — a schema migration before the feature that depends on it, for example. That's not an exception to the rule; it's a sign the task should be split. Break it into subtasks (add_todo or separate linked tasks) and give each its own branch. The convention doesn't bend; the task does.
Setting it up
1. Connect the repository. In project settings, under Git integration, connect the GitHub or GitLab repo the team ships from.
2. Agree on the prefix. task/<id>-<slug> is what WKFGo's webhook parses out of the box. Put the exact format in the project wiki so nobody guesses.
3. Create branches from the task, not from memory. Whether through the create_branch MCP tool or copy-pasting the task ID into git checkout -b, the branch name should never depend on someone remembering the number correctly.
4. Check it in code review for two weeks. A reviewer glancing at the branch name catches drift before it becomes habit. After that, it holds on its own.
Common mistakes
One branch, several unrelated tasks. The moment a second task's work lands in the same branch, the traceability is gone — the branch now represents two things and the history can't tell them apart.
Long-lived branches that drift from main. A branch open for three weeks while main moves on invites a merge conflict that's harder to resolve than the original change. Small, short-lived, task-scoped branches merge before they can go stale.
Renaming branches after the fact to "fix" the link. If the task ID was wrong from the start, use attach_commit or attach_pr to link it correctly rather than rewriting branch history — this is the same fix used when a commit already exists without the right task reference.
Treating the convention as optional for "quick" fixes. The five-minute hotfix is exactly the branch that tends to get forgotten and never linked. It takes the same three seconds to name it correctly.
FAQ
What if a task doesn't need a branch — it's a one-line config change?
Small changes still benefit from the convention; the branch can be short-lived and merge within the hour. The point isn't ceremony, it's that the link between code and task exists when someone looks for it later.
Does the pull request need the task ID too?
It helps. If the branch is already named correctly, the PR inherits the link automatically, but putting the task ID in the PR title makes it visible to reviewers who never look at the branch name.
What about branches that existed before we adopted this?
Leave them. Rename churn causes more confusion than it fixes. Apply the convention going forward and the coverage builds up naturally as old branches merge and close.
Does this work with a trunk-based or short-lived-branch strategy?
Yes — branch-per-task and short-lived branches reinforce each other. The task boundary is what keeps branches short in the first place.
Summary
Branch-per-task workflow isn't a tool you install — it's a naming convention the team agrees to and a webhook that reads it. Once a branch's name says which task it belongs to, reviews get smaller, blame gets precise, and the delivery report stops needing anyone's memory.