I often have this discussion of wether a commit message should include the ticket number or not.
In my opinion Ticket numbers are superfluous really. They're only useful if you endeavour to utilise the same Ticketing system for the life of the product (which realistically isn't always viable).
More importantly I believe you should write useful and meaningful commit messages without relying on the ticket as reference. Too many times I've seen people write very poor commit messages all because they feel that the ticket number is sufficient information. However, changing the ticketing system means all context of requested / completed work tied to the ticket + commit, could be potentially lost.
Assuming you have never worked on a large project with multiple simultaneous releases or as a release manager. Being able to tie customer issues to source code changes is critical.
But if we're talking about releases, you would tag your releases , and log the issues fixed and such on your change log. Still don't see a necessity for ticket numbers within commit messages or branch names.
I agree with it being important to add ticket and story # to your commits. Issue trackers and stories on story boards should be able to consume those commit messages and tag them to the problem.
If you switch ticketing or story boards, migrates tickets and stories should migrate the linked commits too.
If you don’t have a system that consumes the #, you either have a small project. Or tech debt.
Grant I agree there is a problem there (too short git messages) but I have to disagree on the solution (don't include ticket # so people can't be lazy). For one thing once the feature branch is merged and the branch name deleted, there is no longer a way of knowing what ticket a particular commit belongs to.
This has been very useful in the past when searching through commits. And not deleting branches is not practical, leads to an absolute mess of branches.
On my teams we agree that the commit message should be detailed enough to understand what changed, and that the why can be obtained from the ticket itself.
And on the unlikely event that the ticketing system changes, I'm my experience that is so rare that it is not worth worrying about.
There will be many other complications to deal with, such as maintaining change history at all vs starting clean.
Also, I would be very surprised if in such situation, the team or IT were not open to allowing view only access to the old system for a while, like 6 months or a year. Beyond that, no one cares much about preserving history of tickets or commits.
That's a good point, yes. Agree in some cases ticket numbers are useful. I think I didn't explain myself correctly, as I was more trying to make the point of Yes , 2e should write descriptive messages and not rely solely on ticket numbers as some do.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
People are not wrong, they should have a different context then you have.
For example we work with the pull request as being the unit of work. When a PR is done,v we squash and merge .So I count l couldn't care less about the the commit message of individual commits.
At the end of the day, git is not our master, it's just a tool
After one commit I create a draft PR(the description has # of the issue)
when I commit to that branch(and PR) all the tests automatically run and maybe even a preview is deployed. This incentives me not to get lazy and actually commit every change. The names of my commits are not really relevant. It obviously can't be "a", "aa", "b", "1234" but it doesn't have to super precise and specific.
when I think I'm done I change the draft PR to a regular PR.
Here's where my responsibilities end.
someone reviews it and changes the name of the PR if I didn't get it right
if it's all good, squashes it and pushes to main.
GitHub automatically sets the commit message to (<# of the PR>) so because the maintainer changed the PR name earlier it's just pressing commit.
Inb4 I haven't worked at a corp with a big dev team. I worked on very small commercial projects and I contributed to fairly large open source projects and it worked there but I can't see why this wouldn't work in a big company.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One thing to have in mind is that git and therefore its supposed "best practices" were developed with a very special kind of projects in mind: bazaar-like open source projects with loads of contributors. Most notably Linus Torvalds's own Linux Kernel project.
If that's what your project looks like, do respect the best practices. If note, feel free to drop the ones that doesn't improve your developer life.
The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary is an essay, and later a book, by Eric S. Raymond on software engineering methods, based on his observations of the Linux kernel development process and his experiences managing an open source project, fetchmail. It examines the struggle between top-down and bottom-up design. The essay was first presented by the author at the Linux Kongress on May 27, 1997 in Würzburg (Germany) and was published as the second chapter of the same‑titled book in 1999.
They say if you get a job where doing something you like you never work a day in your life. I think that's pretty accurate. I'm doing what I've wanted to do since middle school and enjoy going to work
Location
Pacific North West
Education
Computer Science MS, Johns Hopkins University
Work
Software Developer; Integration and Test lead at Progeny Systems Corporation
I think it's important that you have a way to tie commits to a ticket. Ive been on project where pre commit hooks in git verified that all check-ins were for open tickets. It's easy enough to just slap a bug-1234 at the top and even easier to ignore them if you don't want to see them. You could mput the commit hashes in ticket but I think more often it's more important on the code side to track what commits are for what bug versus what looking at a ticket to see the commits. I'm thinking for code reviews etc. If yes poor commit messages are an issue, but that's an issue that exists independent of anything else.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I often have this discussion of wether a commit message should include the ticket number or not.
In my opinion Ticket numbers are superfluous really. They're only useful if you endeavour to utilise the same Ticketing system for the life of the product (which realistically isn't always viable).
More importantly I believe you should write useful and meaningful commit messages without relying on the ticket as reference. Too many times I've seen people write very poor commit messages all because they feel that the ticket number is sufficient information. However, changing the ticketing system means all context of requested / completed work tied to the ticket + commit, could be potentially lost.
Tickets help enormously because PMs don't add information to the commit message. How do you ever determine what customer requested a specific feature?
Assuming you have never worked on a large project with multiple simultaneous releases or as a release manager. Being able to tie customer issues to source code changes is critical.
But if we're talking about releases, you would tag your releases , and log the issues fixed and such on your change log. Still don't see a necessity for ticket numbers within commit messages or branch names.
I agree with it being important to add ticket and story # to your commits. Issue trackers and stories on story boards should be able to consume those commit messages and tag them to the problem.
If you switch ticketing or story boards, migrates tickets and stories should migrate the linked commits too.
If you don’t have a system that consumes the #, you either have a small project. Or tech debt.
Grant I agree there is a problem there (too short git messages) but I have to disagree on the solution (don't include ticket # so people can't be lazy). For one thing once the feature branch is merged and the branch name deleted, there is no longer a way of knowing what ticket a particular commit belongs to.
This has been very useful in the past when searching through commits. And not deleting branches is not practical, leads to an absolute mess of branches.
On my teams we agree that the commit message should be detailed enough to understand what changed, and that the why can be obtained from the ticket itself.
And on the unlikely event that the ticketing system changes, I'm my experience that is so rare that it is not worth worrying about.
There will be many other complications to deal with, such as maintaining change history at all vs starting clean.
Also, I would be very surprised if in such situation, the team or IT were not open to allowing view only access to the old system for a while, like 6 months or a year. Beyond that, no one cares much about preserving history of tickets or commits.
That's a good point, yes. Agree in some cases ticket numbers are useful. I think I didn't explain myself correctly, as I was more trying to make the point of Yes , 2e should write descriptive messages and not rely solely on ticket numbers as some do.
I agree.
Fair enough
The ticket numbers are good for automation. Let hooks do their thing and you can avoid dealing with Jira.
People are not wrong, they should have a different context then you have.
For example we work with the pull request as being the unit of work. When a PR is done,v we squash and merge .So I count l couldn't care less about the the commit message of individual commits.
At the end of the day, git is not our master, it's just a tool
Yup. I think this workflow is quite good:
Inb4 I haven't worked at a corp with a big dev team. I worked on very small commercial projects and I contributed to fairly large open source projects and it worked there but I can't see why this wouldn't work in a big company.
Sounds good to me.
One thing to have in mind is that
gitand therefore its supposed "best practices" were developed with a very special kind of projects in mind: bazaar-like open source projects with loads of contributors. Most notably Linus Torvalds's own Linux Kernel project.If that's what your project looks like, do respect the best practices. If note, feel free to drop the ones that doesn't improve your developer life.
The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary is an essay, and later a book, by Eric S. Raymond on software engineering methods, based on his observations of the Linux kernel development process and his experiences managing an open source project, fetchmail. It examines the struggle between top-down and bottom-up design. The essay was first presented by the author at the Linux Kongress on May 27, 1997 in Würzburg (Germany) and was published as the second chapter of the same‑titled book in 1999.
Thanks for your thoughts.
I see a short-term benefit of referencing an issue in the commit message. But I agree, in the long run, those possibly do not work anymore.
I think it's important that you have a way to tie commits to a ticket. Ive been on project where pre commit hooks in git verified that all check-ins were for open tickets. It's easy enough to just slap a bug-1234 at the top and even easier to ignore them if you don't want to see them. You could mput the commit hashes in ticket but I think more often it's more important on the code side to track what commits are for what bug versus what looking at a ticket to see the commits. I'm thinking for code reviews etc. If yes poor commit messages are an issue, but that's an issue that exists independent of anything else.