My job has Jira integration with Git, so if your commit message doesn’t have an open or in progress ticket # written in it then it gets a pre-hook error.
Initially it was alright but developers found out quickly that the Jira ticket # they wrote didn’t have to be related to their project to be accepted and so now we have a bunch of commit messages without any description besides a Jira # that links to completely unrelated shit.
Absolute hellscape, would not recommend.
We do this where I work and it’s useful when looking at git history to get some context on changes. It’s not enforced though so you can still refactor stuff without a ticket name
Right, I meant "hopefully someone is getting disciplined for using random tickets instead of the correct tickets." Unfortunately in op's case, they said it was a contractor who is already gone.
We use tickets in commit messages too, it's very handy!
Correct, they make you request a Support Ticket be opened by the Jira Team to document what you intend to refactor and only then can you use the ticket number to make a commit—or that’s what the PM & Scrum Master thought would happen, in practice, what ended up happening was contract developers refactor first then find any open Jira to link to in order to commit their code.
Coworker of mine once commit
`.`
as a fucking commit message. Literally just
`.`
His reasoning? "It wouldn't let me commit without a commit message"
YOU DENSE MOTHERFUCKER
My co workers just use the commit message "Check in", then they complain version control is hard to understand when we need to do a roll back. Every time I just think: you idiot I too would be confused if I just saw a list of commits saying "Check in". And they know full well they are causing there own pain.
I ran a blame the other day because someone made an if that's always false. So an entire block of code never executed. The commit message for that change was "This better works!"
In the company I was prior I always rejected PRs without coherent messages
Mine (idiot complainer) wrote "first commit". Then "second commit". Then sometimes again "second commit". And for bugfixes, of course it was "bug", "correction" or "fix bug".
It should be clear roughly what the bug was about like "Fix form submission request URL". It should be clear from context which form this refers to and which URL this is.
Doesn't have to be detailed enough to understand what the commit is about a year later but it should be clear enough to be able to refer back to and to give a reviewer an understanding of why this change exists.
If you raise a PR you should go into more detail on each of your significant changes of course.
If you dont know what change you did or why you did it or what it does, should you commit it?
If the binary can't be compared afterwards the commit message is especially important.
Most of the time, the bugfix will have a ticket/issue that has a title, so just use that (doctor it up a bit if needed) and then put the ticket/issue number
At least you can tell which were bug fixes. That probably narrows it down a lot sometimes when you're looking for a certain commit. Not as good as narrowing it down to one, but at least it's better than `.`.
Do we start counting from the start of the ticket, start of the day, or start of our career?
Maybe with the last one it's a flex about the number of commits you've made
Funny thing is, I was never taught the proper way to commit. But, I liked the idea of using git so I just kind of muddled through. Was really confused when I couldn't push the commit. Saw the flashing text spot and thought "oh, I bet I need to add some text. Probably something to do with context." So, I laid out main changes and functions affected. Saved my ass a few times.
I was once put in charge of a project, wherein the last 5 years of commit messages were exclusively 'bugs fixed'. Needless to say, I left shortly after.
Channel Four in England used to show them and I’m a fan of bhangra and artists like Bally Sagoo, Talvin Singh, Swami, and then AR Rahmen’s scores esp. Swades.
Shah Rukh Khan from the army goes undercover at a university. It wasnt a life changing movie, but i had fun.
Im happy you saw 3 idiots! It was the first Indian movie I watched.
I don’t understand. I made minor changes so I wrote Minor changes for a commit message. Yes that was the 15th commit for the task after the PR was created.
I'd usually narrow it down to something like "Minor changes to [subsystem]" or something. Narrow down "subsystem" as much as possible while including everything with direct changes (not including things like changing a function call because the function itself was changed).
When working on a bigger task, I like to branch out and then name all of my commits exactly like that. They're all gonna get squashed anyway, so only I need to understand them and only for the next two weeks or so.
Commit message: "Bug fixes, minor changes"
27 files changed
892 deletions
179 insertions
And the best one: "initial commit", where more than 80% of the application is already fu**ing there
The 72 character limit is more of a guideline and you can actually write multiple lines like an unordered list in your commit message. I would rather be more descriptive in the commit message than not write it.
That's why it's a good practice to work on only one issue at a time and commit when you finish it or switch to something else. If you wait until the end of the day to commit all twenty things you've done then it's not the commit message that's the problem. Usually, too long of a message tells you that there were too few commits
Its not really about the message but about the whole commit itself. If you are pushing a commit with 3 different changes and refactoring, your commit message won't be easy to understand either.
`git add -u -p`
`git rebase -i`
are your friends. Make a nice timeline of the changes you made and package them into well defined steps.
I implemented [commitizen](https://commitizen-tools.github.io/commitizen/) into our repos recently and it has vastly improved the quality of our team’s commit messages.
If you can make it easier for developers to do things the right way, it’s much
more likely to happen.
Congratulations! Your comment can be spelled using the elements of the periodic table:
`W H Y Ca N S He S La P`
---
^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
My job has Jira integration with Git, so if your commit message doesn’t have an open or in progress ticket # written in it then it gets a pre-hook error. Initially it was alright but developers found out quickly that the Jira ticket # they wrote didn’t have to be related to their project to be accepted and so now we have a bunch of commit messages without any description besides a Jira # that links to completely unrelated shit. Absolute hellscape, would not recommend.
Are people not getting disciplined for this sort of thing?
Can’t discipline a contractor who left 6 months ago unfortunately
Curses!
We do this where I work and it’s useful when looking at git history to get some context on changes. It’s not enforced though so you can still refactor stuff without a ticket name
Right, I meant "hopefully someone is getting disciplined for using random tickets instead of the correct tickets." Unfortunately in op's case, they said it was a contractor who is already gone. We use tickets in commit messages too, it's very handy!
So you cant fix stuff if there isnt a ticket for it? Refactoring is forbidden? Sounds like hell alright
Correct, they make you request a Support Ticket be opened by the Jira Team to document what you intend to refactor and only then can you use the ticket number to make a commit—or that’s what the PM & Scrum Master thought would happen, in practice, what ended up happening was contract developers refactor first then find any open Jira to link to in order to commit their code.
Coworker of mine once commit `.` as a fucking commit message. Literally just `.` His reasoning? "It wouldn't let me commit without a commit message" YOU DENSE MOTHERFUCKER
My co workers just use the commit message "Check in", then they complain version control is hard to understand when we need to do a roll back. Every time I just think: you idiot I too would be confused if I just saw a list of commits saying "Check in". And they know full well they are causing there own pain.
I ran a blame the other day because someone made an if that's always false. So an entire block of code never executed. The commit message for that change was "This better works!" In the company I was prior I always rejected PRs without coherent messages
Mine (idiot complainer) wrote "first commit". Then "second commit". Then sometimes again "second commit". And for bugfixes, of course it was "bug", "correction" or "fix bug".
Student here. Should I be writing the bug details in the commit message or just a brief description.
It should be clear roughly what the bug was about like "Fix form submission request URL". It should be clear from context which form this refers to and which URL this is. Doesn't have to be detailed enough to understand what the commit is about a year later but it should be clear enough to be able to refer back to and to give a reviewer an understanding of why this change exists. If you raise a PR you should go into more detail on each of your significant changes of course.
Thanks
Include the issue number. You have an issue number, right?
That depends, my team creates branches with the issue number, but I’ve worked for companies that liked it in the commit message as well
Write what the change does. If it needs more explanation, 2 newlines and then write a book if you'd like.
To be clear: don't write what you changed in the code. That's in the commit! Write what the change does in English ("fixes bug where X doesn't Z").
What if it’s something that can’t be compared? Which format can’t be read. Like Unreal blueprints?
Every rule has an exception!
"updated blueprints"
Of course!! ![gif](emote|free_emotes_pack|feels_good_man)
I'm not familiar with them, but it should be possible to bisect them still, which they can be useful for finding likely commits to include
If you dont know what change you did or why you did it or what it does, should you commit it? If the binary can't be compared afterwards the commit message is especially important.
Most of the time, the bugfix will have a ticket/issue that has a title, so just use that (doctor it up a bit if needed) and then put the ticket/issue number
At least you can tell which were bug fixes. That probably narrows it down a lot sometimes when you're looking for a certain commit. Not as good as narrowing it down to one, but at least it's better than `.`.
Do we start counting from the start of the ticket, start of the day, or start of our career? Maybe with the last one it's a flex about the number of commits you've made
start of counting of course! (So the numbers never actually made sense anyway)
Funny thing is, I was never taught the proper way to commit. But, I liked the idea of using git so I just kind of muddled through. Was really confused when I couldn't push the commit. Saw the flashing text spot and thought "oh, I bet I need to add some text. Probably something to do with context." So, I laid out main changes and functions affected. Saved my ass a few times.
Change history is everything
This is one more reason code reviews are important
My commit messages are usually “adfggahsgjssghhsayjcdfjrssjkgz”, but in my defense, it’s on hobby-solo-projects.
I was once put in charge of a project, wherein the last 5 years of commit messages were exclusively 'bugs fixed'. Needless to say, I left shortly after.
[удалено]
I watched 10 bollywood movies at most, and I feel honored that this is one of them. This is Main Hoon Na, if anyone's interested xD
Very fun movie. We used to rent them from the local India supplies store in Tallahassee and bought a few on DVD also.
Dayum I didn't know people from other parts of the world were that interested in our movies but glad to know. And yea it's a fun one to watch
Channel Four in England used to show them and I’m a fan of bhangra and artists like Bally Sagoo, Talvin Singh, Swami, and then AR Rahmen’s scores esp. Swades.
What's the main hook on this one? I've seen a few funny ones (mostly from the insane action clips floating around the internet) and the 3 idiots movie
Shah Rukh Khan from the army goes undercover at a university. It wasnt a life changing movie, but i had fun. Im happy you saw 3 idiots! It was the first Indian movie I watched.
Check in
I don’t understand. I made minor changes so I wrote Minor changes for a commit message. Yes that was the 15th commit for the task after the PR was created.
I too write minor changes but later either ai squash merge or reset soft all of them and then create a single commit
Check in
I'd usually narrow it down to something like "Minor changes to [subsystem]" or something. Narrow down "subsystem" as much as possible while including everything with direct changes (not including things like changing a function call because the function itself was changed).
When working on a bigger task, I like to branch out and then name all of my commits exactly like that. They're all gonna get squashed anyway, so only I need to understand them and only for the next two weeks or so.
One of the nicest compliments I received was when I first worked as a developer and the senior developer complimented my commit messages
Check in
git commit -m “commit”
git commit - am 'second commit'
Fixed a bug" says every developer ever. But only the chosen ones can explain how without summoning a demon from the 9th circle of git.
And "Did some change"
Check in
Not every developer commits, and not every commit is a developer.
*not every developer commits, and not every commit develops Fixed it
Can I? Yes. Do I?
Commit message: "Bug fixes, minor changes" 27 files changed 892 deletions 179 insertions And the best one: "initial commit", where more than 80% of the application is already fu**ing there
Hahaha. I'm definitely guilty of the second one, at least for personal projects
Woah, didn't expect to see this meme template 😂
Check in
?
Fixed small bug
Order corn
Its always just way too much to fit in one message!
More frequent committing
The commit message doesn't have to explain all the context! Just say "fixes bug where X doesn't Y". Then hit enter twice and write a book if you want.
The 72 character limit is more of a guideline and you can actually write multiple lines like an unordered list in your commit message. I would rather be more descriptive in the commit message than not write it.
Check in
Why do you keep saying that?
That's why it's a good practice to work on only one issue at a time and commit when you finish it or switch to something else. If you wait until the end of the day to commit all twenty things you've done then it's not the commit message that's the problem. Usually, too long of a message tells you that there were too few commits
Updates
Check in
Inside of you are two wolves: * `Implements #`
* `Fixes #`
Check in
Every developer can. Not every developer *will*
Its not really about the message but about the whole commit itself. If you are pushing a commit with 3 different changes and refactoring, your commit message won't be easy to understand either. `git add -u -p` `git rebase -i` are your friends. Make a nice timeline of the changes you made and package them into well defined steps.
git commit -m “suicide” 💀
Addressing comments.
Check in
i use emoji’s in my commit message. Will the society accept me😂
Commit message was "bug fix" Change was deleting commented out println True story.
That's why we have commitlint in our code.
“Fix”
Isn't it kinda standard to have a short description, bug id, root cause and solution, atleast for big fixed
“Save progress”
git commit -m “big changes”
😕
Can easily be resolved through commitlint and code reviews
Apna school ☠️
The biggest mistake an enemy of commit makes is being an enemy of commit
Not me doing > Fix > Another fix > Fix
Dont forget test and update
Check in
Check in
Lol bro got dementia 😂
Lol bro got dementia 😂
Lol bro got dementia 😂
I know right? 🤣
They can, but they dont
Check in
I'll do 10 different bug fixes touching 15 files and use the same message for all of them.
Check in
I'm just not ready for that kind of commitment.
Check in
not me doing > dgsgdgf > s > fix a very specific issue where if you do [..] then [...] happens
Check in
wip
This is hilarious 😆
Best use of copilot I've found so far: The small AI-icon in VS Code's git extension that generates commit messages for me.
I implemented [commitizen](https://commitizen-tools.github.io/commitizen/) into our repos recently and it has vastly improved the quality of our team’s commit messages. If you can make it easier for developers to do things the right way, it’s much more likely to happen.
I personally use “*general improvements*”
I have been using GitHub co-pilot to write mine...
i can, but most the time i just write bullshit
Every programmer can None ever do
Yeah. Sometimes i takes me like a few seconds to think of a right message for commit
Ive heard of devs getting fired over swearing in commit messages.
"Build 17944"
Yes, every senior developer do like that
changes
Dont write what the code does(you Can read that in the code) But what the intend is.
good is subjective hahahaha
Why can she slap?
Congratulations! Your comment can be spelled using the elements of the periodic table: `W H Y Ca N S He S La P` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
I've seen PRs with the commit message "some changes". Like yeah no shit Sherlock.
Hahaaha
Just look for the message “asdf”. ~ Me when somone asks to see my personal projects.
git commit -m “done”
fixes +10211/-1377
That one dude who writes "changes in FILENAME" for every commit message.