What Are You Doing?

Risks

People have mixed feelings about a practice like requiring developers to add tracking information into commit messages by hand. Traceability is nice, but having to assign every item to a work item can add overhead and lead to micromanaging. This is certainly a risk, but you can introduce the practice by making clear that the goals are about focus, not supervision.

To that end, you need to agree on a specific granularity of what to track. A Scrum team might start with a product backlog that consists of a small number of coarse-grained stories. [4] At the start of the sprint, the team may divide the stories into tasks. For the purposes of keeping focus, tracking at the story level is appropriate.

Likewise, people may assert that side issues may come up and requiring issues for every commit sounds bureaucratic. You can capture this with placeholder issues, and provide feedback for improving your issue creation process.

You may also say that not every change, such as fixing a typo, is relevant to the story. If you did the work in service of the story, it is relevant, so say so.

Implementation Tips

To get the most value and traceability while minimizing overhead at coding time, you want to have an approach that is simple to implement. It should be easy to add this level of traceability to changes, and easy to overcome problems caused by vague story definitions and other planning missteps. You also want to provide an easy way to add data on how the task-level tracking worked so that you can analyze this during the retrospective. This can be accomplished in several ways:  

For the purposes of assigning issues to commits, focus on high-level tasks (stories). Try to group the work for an iteration into a small number of stories.

Give each high-level feature in an iteration (story) a mnemonic. If you are using an issue-tracking system, there usually is an issue ID. If you are using a paper-based system (index cards), add a mnemonic to the card.