Branch per ticket: always know where the code is
A bug comes back and nobody remembers which branch held the fix. A client asks whether their request is live yet, and you spend ten minutes searching Git. A few fixed agreements about branches and commits put an end to that. Here is how to set it up.
1.One ticket, one branch
Start every piece of work from a ticket. If the work is too big for one branch, the ticket is too big: split it into subtasks, each with its own number. That keeps a pull request small enough to review properly.
2.The ticket number in the branch name
Agree on a fixed format, such as feature/ASUP-12-short-description or fix/ASUP-14-ideal-callback. The prefix says what kind of work it is, the number says which ticket it belongs to. Tools that recognise the number can then link the branch automatically.
3.The number in every commit
Put the ticket number at the start of your commit message: ASUP-12 validate login form. Even if a commit later ends up in another branch, you can see which ticket it belongs to. With smart commits you update the ticket at the same time, for example with #time 45m or #review.
4.Pull requests update the ticket
Let an opened pull request move the ticket to In Review, and a merge mark the branch as merged. The status on the board is then correct without anyone having to think about it.
5.Check it in your review
Make it part of your review agreements that the ticket number is in the branch and the commits. A pull request without a ticket goes back. After a few weeks, everyone does it automatically.
In summary
- One ticket, one branch
- The ticket number in the branch name
- The number in every commit
- Pull requests update the ticket
- Check it in your review