I was wondering if it would be good practice for commit messages to contain the ticket number they were apart of. It would be like
2568 Fix heating issue
Summary of the issue with a bunch of detailed comments
It would be a bit of a pain to get the ticket or isse # in each commit and I am wondering if people think it would be worth it in the long run. Also if my branch has the ticket number is this redundant? The main issue is that I use source tree and that in the log / history view it can get a little complicated to see what commit corresponds with what ticket. I just would like a better way to see how everything works.
Yes, this is a good idea and fairly standard (but not universal) practice.
The specific software engineering goal you are achieving with this is requirements traceability. The idea is you want to be able to trace a requirement through the entire software process:
By using ticket or requirement numbers (e.g. Jira story IDs) in commit messages and any correspondence, you are working toward that software engineering goal.
If I come back a year later and see the commit message, I can look up that number in another system to get the full background behind the requirement or ticket, including anything that occurred after the commit.
The downside is that people will write less complete commit comments because someone can go to the ticket for more details. This is only really a problem if you say switch to a different ticketing system and can't keep the history or someone doesn't have ticketing system but does have access to the repository.
If the branch is already named for the ticket I wouldn't bother putting it in the commit, that does seem redundant.
If your system tracks all features/bugs then you likely will have a ticket of some sort. But if your system only tracks bugs (for some reason?) and all new development is a free for all.
Some significant advantages:
Some VCS/ticket systems allow auto hyperlinks for the ticket number when browsing the commits in the issue tracker (this is super useful, see github, redmine)
It provides some context for the inevitable "why did Simon do this? Makes no sense!" question
Often this might be years later...
Context for changes can take a lot of work multiple years in the future. Having a ticket with an explanation for why the code was changed can be super, super useful
Helps keep people working on value-add things
"Oh, I'm going to refactor this.. and this.. and this... and... oh I've not done any value-add work in a week!"
Can allow searches to find commits related to an issue
The only disadvantage is if your team doesn't really use tickets or a tracking system. Then it'd be harder to find the ticket number. Or if your VCS and issue tracker don't integrate well.
And... you should track all efforts somewhere, so, if that's why you are not using a ticket system for nearly all of your work I'd strongly suggest doing so, regardless of whether you have it included in your commit messages.
Including reference numbers (tickets, features, requirements, etc.) in commit messages is a great idea. But it should never be a substitute for a good message. At my current employer, we're now on our second source control system, our third ticketing system, and our second requirements management system. Needless to say, the old systems' data were never migrated into their replacements, and even if they were, the numbering systems overlap.