What Are You Doing?

If your work environment leads to a lot of work that is off task, you can use the information from the commit logs to make it easier to identify whether additional work is a reason for not meeting sprint commitments.

Adding the identifier to your commit message should not replace other, contextual information you might have added. “Implemented PROJ-123” is less informative than a message like “PROJ-123: added caching.” Your team needs to agree on the conventions to follow to balance efficiency on the commit and the review sides of a project.

Adding the issue identifier to the message is still a manual process, and it is useful to make it difficult to commit changes without identifying an issue (or explicitly identifying no issue). If your tools enforce this practice, you can re-enforce the team's awareness of the end goal of its work.

Reporting

Adding issue identifiers to your commit messages can help with maintaining focus, but does not provide much opportunity for feedback and improvement unless you also provide a mechanism for getting the information out.

Many issue-tracking systems, such as Jira, [3] have ways of associating commits with issues if you add the issue number to the message. Some CI systems also show which issues were addressed in a given build.

If you don't use a tracking system—or use one that does not make it easy to gather data from the issue system—you can generate some information from tools that allow you to view commit logs. For example, you can write a script that searches through your subversion log history looking for lines that match the pattern of your issue mnemonic, allowing you to   generate a list of commits that were associated with an issue.