> Unless someone manually comments about it or your tooling picks it up based on references.
I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development.
We use the following policy:
- A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements.
- The bug tracking system observes the git tree and maintains its own linkage to it.
- When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`.
That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.
I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development.
We use the following policy:
- A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements.
- Bugfix commits always cite the bug tracking system's ticket number.
- The bug tracking system observes the git tree and maintains its own linkage to it.
- When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`.
That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.