11

I'm working on a project where we have the source control set up to automatically write notes in the bug tracker. We simply write the bug issue ID in the commit message and the commit message is added as a note to the bug tracker.

I can see only a few downsides for this practice. If sometime in the future the source code gets separated from the bug tracking software (or the reported bugs/issues are somehow lost). Or when someone is looking in the history of commits but doesn't have access to our bug tracker.

My question is if having a bug/issue reference in the commit message is considered good practice? Are there some other downsides?

Improve this question

4 Answers 4

Reset to default
10

We have adopted this practice and it works very well for us. The tight integration between version control system (VCS) and other systems we use, e.g. continuous integration, bug tracker, etc. is extremely valuable. If we ever change anything in the future we certainly will have to assess the side effects, including the links between the VCS and bug tracking system.

In general I would see this as good practice. For some tracking systems there are additional options and tools available, for example bugtraq properties for Subversion (SVN). This suggests that quite a few people see value in this practice.

Improve this answer
13

If you want to make really, really sure that no information is lost even if you may use a different bug tracker in the future or your bug tracker data somehow disappears, why not just put both the issue ID and a short explanation about the bug into the commit message?

Fix bug #123: app crashed after login

Then you still have the link from the history of commits to the bug tracker - and if the bug tracker should ever be not available, you can still see in the history what this particular bug was about.

Improve this answer
3
  • We actually do that, so we don't have to switch to bug tracker every time we browse through the history of commits.
    – Christian P
    Nov 24, 2011 at 21:24
  • Okay, then I would just leave it as it is. IMO, this is the best way how you can do it!
    – Christian Specht
    Nov 24, 2011 at 21:25
  • 1
    Yes, good point. That was my assumption anyways, though. Just the bug/issue ID alone isn't good enough in my experience. Looking at the commit log you still want to see what each commit was about, e.g. what was the broad reason for this code change. Sometimes the commit message is more on the technical side while the text for the bug tracking system is geared more towards users of the software.
    – Manfred
    Nov 24, 2011 at 21:26
2

This is very common practice, and I have found it extremely convenient. I use TRAC, so I can read the code history and navigate to the task that drove the change, or read the task history and navigate to the code changes.

"If sometime in the future..." If you separate the code from the bug tracker, then the old revision history probably won't be of further interest.

Improve this answer
2

I use this practice too and I consider it a very good one. But besides the issue ID, I add a short description of the bug / feature (usually the title from the bug tracking system). This often helps save time because I don't have to lookup in the bug tracking system (beacuse I recognise the change) AND, like you said, if somehow I lose the bug tracking system, I'm not completly lost.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.