I bet you already heard something about Git before starting this article whatever led you here, you’re welcome and I hope you find the solutions.
...
For further actions, you may consider blocking this person and/or reporting abuse
Several companies I’ve worked at wanted us to prefix our commits with the Jira ticket number e.g MIN-1533. So you can look through the commit history and see right away which ticket the person was working on.
This works excellently up until the point where it generates links or comments on the ticket itself. I've stopped using ticket IDs in commit messages because of that spam, and I rely on GitLab to reference the merge request (which does have the ticket ID) now.
On a different occasion, I found that ticket IDs do, in fact, expire when the ticketing system changes, so it becomes useless information then, too.
Overall, I've stopped caring about commit messages. I care about the context of the changes (especially on bisect or blame), but the message? Screw that. Give me well-contained commits. Rebase your branches before your Merge/Pull Request, sort them into commits that make sense from their contents, and give it a reasonable message that reflects what the commit was kinda-sorta supposed to do. Beyond that, don't waste time on commit messages.
I was gonna mention the ticketing system changing. Happend to me in the past we moved to a different Jira board so a lot of links did now work anymore
For us, it was a switch from Bugzilla to Jira, and then from one Jira project to four. Effectively, six years worth og tickets gone. And at the time, a lot of developers did not care for making their commits self-explanatory, so we had one giant 100k line commit, and dozens of useless oneliners, all with messages that referenced one non-existent ticket. That was hell. So I've stopped caring about messages - and begun caring greatly about tooling associating those commits with the merge, and commits containing relevant information to relate the changes to the business requirement.
You can comment/transition/log jira tasks with commits without even opening jira. For example: git commit -m "JIRATICKET12 #time 1w #resolve #comment Jira comment"
support.atlassian.com/bitbucket-cl...
I put them at the end of the headline. What is neet is that Bitbucket transforms them to direct link to the corresponding Jira tickets .
That makes a lot of sense for companies, thanks for that.
There's actually a specification that covers this topic called Conventional Commits: conventionalcommits.org/en/v1.0.0/
Yes, I used this when writing the article. Thanks for sharing.
you should at least mention them in your article. without this, it sounds like a huge uninformed rip-off rather than an explanation of it.
Actually despite this is a good writing, a lot of cases restrit you from using it. Like big companies, where the ticket numbers are a must to include, or other restrictions. In the other hand, a lot of big companies does not give a fork about git commits, when I worked for Bl*kR*k, they only used master branch for all ther codes pushing from the office located in Delhi and they were just looking at us, why do we want to use several branches for our work to commit? I was frankly stunned... For another company I am actually working now only I am using proper git commits and I always see the backend developer pushing commit with messages like "trying again" and "try #68", "third time the charm", etc... I am really enjoying using proper commit messages, I also created some scripts which creates a release documentation with all the commits between last and recent releases with ticket numbers, descriptions, and changes as countes integers. But as I already said, majority of IT does not think about this as an important thing. But in fact it is.
You should avoid emojis. It might look pretty in a GUI, but for those that use a terminal it might not be as pleasant. It's better to keep it simple.
Thank you
What prefix would be best to use when you're making an update to a feature?
Let's assume you've already added the feature and you're now making an update to it, should you use chore or "update"?
"refactor" changes the implementation of existing functionality. No observable change from the user's perspective.
"feat" can add a new feature or introduce breaking changes to existing functionality. Add "BREAKING CHANGES:" to the commit body or an exclamation point to the commit type, for example "feat!: make name parameter mandatory" for an API.
Does your update add a feature enhancement or simply change implementation. I would use feat for the former and change for the later.
You could also use feat, I wouldn’t want you to overthink it
I’m not really sure and I wouldn’t love to direct you wrongly
Nice work
Thanks
Thanks for the post
Thanks for writing this.
Thanks for this.
More people need to know this.
I've been using "feat:" all my life and now, I'm literally ashamed 😭. Thank you Segz, for bringing an end to my embarrassment.
Thanks Brown
good read
Thank you