Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers 4

up vote 8 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '11 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 '11 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 '11 at 21:26
    
This has generally been the standard practice where I have worked also, I think it's the right way to do it. –  Carson63000 Nov 25 '11 at 3:23
    
+1 always do this! I just took on maintenance of a project that is filled with gems like "this may have been the cause of bug 5423" We don't have access to their bug tracker. –  Kryptic Nov 25 '11 at 14:52
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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