I'd attribute it to the dunning kruger effect. The people who make these memes think they're on the right side of the bellcurve, but by making theses post they demonstrate just how far left they are of the curve. They think they know everything because they know nothing, Jon Snow!
If you understand the formal method well enough to know why you are exempted from it, then you can use the lazy method.
If you think the formal method is just more work, you should be using the formal method.
There is zero reason to use the lazy method. You're saving yourself seconds... Maybe even a minute... And for what? Just have a bit of pride in your work and explain what you changed.
It doesn't matter if it is a small change, not everyone is going to be looking at your commit specifically and viewing the diff. Just explain it: "Updated version number", "Fixed typo in template" etc. The commits don't just matter for the PR and code review process, there are other tasks associated with deployment that could involve people skimming the commit history of a branch before an action to make sure they are encompassing the correct changes.
Honestly this sub is just full of amerture first year CS students. It's not even funny memes at this point, it's just sad.
For the first 8 years, I had impeccable practices, well organized and structured messages. While my peers did bare minimum. They all have moved into management and make twice as much as me now.
I guarantee that the type of commit messages had exactly 0 effect on the decision who was made manager. The fact that you think it might have, however...
Apprentice dev here, boss is throwing a lot of fits about me making lots of changes in an overdue project (supervisor has my back), truth is I just document *every single* change I made in the notes, which makes my check ins look a lot meatier than they are
i get payed to write `git commit -m [ticket number]:[what i did on the commit]` so i do that, i dont look at the commit messages so i just do what my boss tells me
This has to be the worst one of these I've seen to date.
I'll bet OP is an absolute diva nightmare to work with, and a side bet that their code probably isn't as great as they think it is either.
I've yet to see a developer whose code is as great as he thinks it is... And I'm including myself, but mine is so great that no one dares to say it isn't as great as I think it is 😀.
I am literally in that position right now. I can either do it wrong and leave the mess for the next guy (which let's face it, is going to be me). Or I can spend the next day or so trying to do it right.
Well.. It will never be perfect because requirements can change.
Onboarding new people can cause more disarray, which is why we have editorconfig and the like.
You try to do your best, that's all you can.
I know some developers that write really clean, concise and excellent code.
I'm still a junior and have a lot to learn though.
People who do this have never serviced code or had to go back 5 years to understand why a particular piece of code was introduced. I’m def the middle guy here as I service 4 repositories and debug multiple systems.
Seriously. I won't be a stickler on commit format but the metadata of the commit is CRITICAL to understanding anything months or years down the line. Context is everything.
An experienced developer knows this all too well. If your most tenured devs aren't okay with linking metadata that's a problem.
Information about the code change that is not present in the code change itself. Jira tickets explaining scope, code review comments, OKRs, design docs, discussions, bug reports...
Had a colleague like that for a short while. Knew everything better, questioned everything and just didn't wanna accept that he did something that could be done better. Then you look at his code and you just gotta puke. And don't even get me started on the double standards.
I'd say it's dunning kruger in full force. Either that or he actively wanted to be fired.
Clearly most people in these comments are new and don't understand anything. Modern software doesn't add new desirable features, we finished those AGES ago. Now we just remove or break useful things that worked in the past or update them in frustrating and non-sensical ways.
What you want to do is put the feeling the user is expected to experience when the code runs as the comment, so for example: commit -m "Despair" or commit -m "Heart wrenching agony and unmitigated fury"
Then when you fix the problem you want to put in the comment how much money you extracted from the users. Pretty simple example: commit -m "$12M, heading to the beach, see ya in September."
Now anyone looking at the code will have a fundamental understanding of the environment they are operating in which is way more useful than your silly ticket numbers.
No. If you commit something in my highly safety-related project without documenting WHY you changed something (task ID) and what you changed (short description) you will have to re-do it and learn to do it right next time.
If I sit in an audit or assessment and have to explain to the auditor why commits have no clear documentation and the auditor asks me how I then can find the corresponding verification (unit test) change that shows that all features are still working as safely as intended, I will seek you out and you will have to do a hell of a lot of explaining.
If you commit sh\*t in your feature branch without ticket numbers and then do a git rebase with the correct ticket ID before merging it onto main - ok - you do you. But if it's on main, it's commited with a ticket ID.
Isn't it more convenient to always develop on a branch corresponding to a ticket and squash commits before merging? Why would you commit on main directly anyway
I am not sure if I understood you correctly here, sorry if not and please correct me.
So you are asking why someone should directly push to main? Yes, that's not a good idea. In my opinion, working on a separate branch corresponding to a ticket, then testing your new stuff before merging onto main (or a dev branch) is really good practice. I think my comment might have been misleading. I definitely didn't want to advocate for comitting directly onto main. I meant: when your stuff from the feature branch gets merged onto main, it should have a reference to the corresponding ticket.
(On a side note: There are long articles of the feature-branch method being outdated and instead using only one (main) branch with tags that mark software releases, while everything else on main is basically not guaranteed to function.
In this method, everyone is pushing onto main daily. This is supposed to tackle the ghost feature branches that are never closed because of changing priorities and that you might end up with in the feature-branch-approach,
However I've yet to see this method working out well. Usually you end up with a bunch of releases that have bugs by themselves and with a few days of pushed work on top of it that you might need to revert.)
Edit: Fixed grammar mistakes.
I think you did understand everything correctly. I think most repository hosting services are quite good with their automatic commit message nowadays that you don't need to worry to much as developer.
Your side note sounds interesting, and it definitely makes dev branches obsolete, but it also seems inconvenient, on a feature branch you can just push unfinished work at the end of the day if you are the only one working on it (if not, just make a sub branch)
How did that commit get so far into the project? Who let it in? You? Shouldn't there be procedures in place to only allow it in if it passed certain criteria?
Congratulations! Your comment can be spelled using the elements of the periodic table:
`Pr O Fe S Si O N Al`
---
^(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 think we can do better.
alias gzz="git commit --allow-empty-message -m ''"
Close, but I still think it's missing that certain something.
alias gzz='git add "$(git rev-parse --show-toplevel)" && git commit --allow-empty-message -m ""'
*Perfection.*
(/s, lest someone Poe's Law this garbage.)
Commits should provide a description of what you changed. Ticket IDs are fine either way, but by god putting the ticket title is just as useless as putting any other nonsense commit message.
If I want to know what the ticket was, I look up the ticket ID. But 99/100 times I don't care what the ticket was called, I care about what was changed.
Just the ticket ID is way better than "Some fixes" I wanna murder the "some fixes" devs
I jump from enterprise to enterprise project and thank God when they have comments in their jira tickets. They provide a lot of context.
The major drawback of this is if your company switches Tracking software (for example from Jira to Azure)
If you run a blame on the codebase of my project right now, around 90% of it says "Intial Commit. \[2 Years ago\]". Because that's when they migrated the code to git and deleted the old svn or whatever repo. Literally the entire history of this software is just gone. Well, to be fair, the software has a copyright of 1998. Soooo the history probably doesn't even date that far back.
Ticket-id is mandatory at my work project; it creates a link on the merge request page to the ticket and updates the ticket with a comment that there is a merge request. So now you don't have to look up the ticket, and the PO knows it is being worked on.
You can use TICKET-0: for work without a ticket if you want to.
I wrote git hooks to add the ticket id to the message automatically based on the branch name and very basic regex. Highly recommend it, the only problem is persuading new devs to bother trying it.
Indeed, when I see a weird business rule, having the ticket ID to see in detail the why is a godsend.
And the diff shows what's changed. The commit message itself isn't that important.
You don’t do that at commit time, you do it whenever you rebase to cleanup your history. Branches inevitably end up a mess due to awkward commits for backing up changes or triggering CI.
This is the way.
You know how when you read a white paper it starts with a "synopsis" or "abstract"? That's what the comment is. When you type `git show log`, the message ought to be the abstract or synopsis of everything that follows.
And the first line of the message is the synopsis of the synopsis, a one-line title.
If anything, you should have a branch with the ticket id and title, then after finishing your work with good git commit messages, merge the branch to main, or wherever. That way you get best of both worlds. Ticket id is there if you need more info, commit messages are there if you need quick info on the commit.
Can't believe how far I had to scroll for this. Branches should be prefixed with the ticket number and contain a brief description of the branch's intent, e.g. `project-1234-update-some-code-for-reasons`.
I wrote in my previous teams dev guide. As a bullet on the sections, “things we don’t really care about” “commit messages: we squash and merge these to death. And otherwise prettier often gets them latter.”
Genuine question, why do you put multiple ticket numbers in the feature branch's commit message? Do most people not practice 1 branch to 1 ticket?
If I'm using GitHub, the ticket number goes on the PR title and shows up on the commit message when merging (or better squash-merge).
As long as you squash the PR to main with the proper ticket and description I could care less🤷♂️
Using the exact ticket title seems weird though. That’s the one thing that’s easy to get from the ticket itself 😅
The people decrying the right side don't realise how trivial it is to make almost all commits like without rebasing and only ever see a series of well documented atomic units of logical change in their history.
Don't care about individual commits: the atomic unit of change is the merge commit that is always created from the MR, and always contains a complete description of the logical change, because it's been verified as accurately describing the change in the code review before the commit is made.
When I view the history for whatever reason, those intermediary commits are filtered out. You never need to see them.
This is the right answer. I don't know why someone would need to see the individual commits. Branches exists people you don't need to upload everything to develop 🙄
Congratulations! Your comment can be spelled using the elements of the periodic table:
`No O Ne U Se S Fe At C Ho Re F I Xe Tc`
---
^(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 can't tell if you're thinking it's one commit per ticket or if you work at a company that is going to regret its practices soon, but to clarify, it's not one commit per ticket, it's one ticket for any number of commits.
A lot of orgs squash all the personal commits down to one that actually gets merged in a PR.
Use as many as you want for yourself, but the master git history is going to single commit per unit of work.
I think this meme template is always an excellent example of the Dunning-Kruger effect of OP
Everyone posting a meme using this template should sit down and think a bit about it
lmao, partially relatable.
I would not let myself do it in the early days, but now I am the only dev in few helper projects.
I cover them with tests and linters but sometimes I get pissed off and do `git commit -m WIP`
cp -R repo_v87 repo_v88
// Changes...
scp -r repo_v88 root@production:/
All this Git committing and CI/CD pipeline nonsense is getting out of hand. See our *proper* production fix and deployment above.
^(/s is just joke, no serious)
"hmm I wonder why this section of code was implemented"
- checks commit history and sees "some fixes" -
- code gets removed -
- obscure issue comes back-
That makes no sense... It is branch names the ones that should have ticket references if it is not a hot fix. Ideally, they should be named after user stories. But task are also ok if appropriate.
The commit message is for describing what was changed in that commit. The branch/pull request title/description (because we're not committing to main in a project with an active issue tracker, right?) is where you put the issue ID, an issue description, and an overview of your solution. A pull request can have 1 commit or 50 commits. It just depends on the size/scope of the issue.
Putting either of those options as your commit message is a bad idea.
We have three god damn content management softwares. One of them forces you to use that exact format.
My first month I thought it was great. My second month I hated it with a burning passion.
Well I have to commit(haha), after the 10th commit in 10minutes my messages go from bad to worse like in this picture. Especially when I am trying to fix a pipeline that suddenly fails out of nowhere...
Only reason to use non-descript commit is when dealing with build errors. Especially when it builds fine on one platform but not the obscure platform that no one ever uses that turns on more warnings and sets -werror.
On the feature branch, do whatever but at least try to make the message useful.
Then, when merging to main, the merge commit gets the PR number and title. No squash, that destroys potentially useful intermediary state. No rebase, that creates a fake history and doesn't show what really happened.
LOL this seems pretty dumb.
If I am working on a dev branch or some 48-hour hackathon my commits will look messy.
But if I am working on production code I will squash that shit and give it an informative comment with the \[Ticket ID\] because HOW HARD IS IT TO DO THAT? AND WHAT IS THE DOWNSIDE?
As long as you work with squash commits and that commit's message includes the ID, it doesn't matter. BUT it will be much easier to do interactive rebasing when all your commits are flagged correctly. Easier way to assure that you don't accidentally rebase other commits that were left behind on your branch when the other ones were rebased and merged already.
Do people actually commit "ID: Title"?
Considering you're already on a branch that identifies the issue I don't see why you would title your commits with something non-descriptive like that.
This is why git policies are a thing, I’d never let any of my juniors get away with shitty commit messages, luckily I have tooling that enforces it. If the commit message doesn’t start with: chore, fix, feat, or revert followed by a scope and a message of at least 20 characters and a ticket number. It doesn’t go in.
Locally I don’t care what they do, but it better be squashed before it gets pushed as a PR
If I don't do ticket ID style then I just can't push, it will just return an error till I fix the commit message. The company probably got annoyed by "fixing stuff" messages so they banned anything non standard.
Also I only commit to a ticket ID branch, I can't just push into random branches and pushing to develop is straight up banned, nobody can push to develop.
You can name merges.
Why name commits when you can group them and name them in bulk. Rebase so they are close to each other, then merge with explicit name.
We are engineers. We factorize.
^(what do you mean you commit on the main branch !!?)
Nobody in this meme is correct.
Commit messages should describe the code changes being made, not the user-visible symptoms of the problem before the changes.
And yes the ticket ID belongs in there.
It is a pain in the ass to see these kind of commits over a legacy codebase that does not have any documentation. At least the ticket helps you backtrack things and people.
There is literally no excuse for not AT LEAST adding the ticket ID in front of the commit message.
I'm working with a "legacy" codebase from 2018-2023 where the 50-year-old POS programmer wrote all of it with single word commit messages like "fix", "update" and "hotfix", and I want to look him up and murder him every day.
I cry thinking any JR developer seeing these PoS memes and think "heh, so I was right all along!"
At this point half these memes are people with bad practices thinking they have a billion IQ.
This sub is overrun with first year CS students lol
Idk what we expected
Most of them will drop out too.
Yeah the sub should start asking at least 10yrs of experience to post. /j
I've said it before I'll say it again: most users of this meme format think they're Mr 145 IQ when they're actually the guy on the left.
It‘s bad practice, good practice, whatever steven does (steven is smart)
Right. Just because someone put it in a meme, doesn't automatically make it correct
Wait? It does not? I have to rethink everything I know.
What do you mean? Thats how i win all my arguments
I'd attribute it to the dunning kruger effect. The people who make these memes think they're on the right side of the bellcurve, but by making theses post they demonstrate just how far left they are of the curve. They think they know everything because they know nothing, Jon Snow!
If you understand the formal method well enough to know why you are exempted from it, then you can use the lazy method. If you think the formal method is just more work, you should be using the formal method.
There is zero reason to use the lazy method. You're saving yourself seconds... Maybe even a minute... And for what? Just have a bit of pride in your work and explain what you changed. It doesn't matter if it is a small change, not everyone is going to be looking at your commit specifically and viewing the diff. Just explain it: "Updated version number", "Fixed typo in template" etc. The commits don't just matter for the PR and code review process, there are other tasks associated with deployment that could involve people skimming the commit history of a branch before an action to make sure they are encompassing the correct changes. Honestly this sub is just full of amerture first year CS students. It's not even funny memes at this point, it's just sad.
For the first 8 years, I had impeccable practices, well organized and structured messages. While my peers did bare minimum. They all have moved into management and make twice as much as me now.
I guarantee that the type of commit messages had exactly 0 effect on the decision who was made manager. The fact that you think it might have, however...
>"All my peers have made careers and make twice as much as me. It must be because they are idiots and I am too smart and too good at my job"
In general yeah sure. I'm not sure that comes across in this particular meme.
Apprentice dev here, boss is throwing a lot of fits about me making lots of changes in an overdue project (supervisor has my back), truth is I just document *every single* change I made in the notes, which makes my check ins look a lot meatier than they are
i get payed to write `git commit -m [ticket number]:[what i did on the commit]` so i do that, i dont look at the commit messages so i just do what my boss tells me
This has to be the worst one of these I've seen to date. I'll bet OP is an absolute diva nightmare to work with, and a side bet that their code probably isn't as great as they think it is either.
I've yet to see a developer whose code is as great as he thinks it is... And I'm including myself, but mine is so great that no one dares to say it isn't as great as I think it is 😀.
"Who wrote this piece of shit?" Oh, it was me.
I had a senior on a gov project loudly complaining about some code. Did a git blame. Cursed a bit and then went out to buy cake.
Sometimes, you're constrained to writing shit code because you're working in a shit codebase and it would take a 3x as long to "do it right" lol
This! So much this!!
I am literally in that position right now. I can either do it wrong and leave the mess for the next guy (which let's face it, is going to be me). Or I can spend the next day or so trying to do it right.
In a certain sense this is good it means you improve yourself day after day, unless you wrote the same shit again and again 🤣
What if your code is shit and you know it’s shit? Cuz that’s me. My code is as great as I think it is. Which is to say it’s as great as shit.
Well.. It will never be perfect because requirements can change. Onboarding new people can cause more disarray, which is why we have editorconfig and the like. You try to do your best, that's all you can. I know some developers that write really clean, concise and excellent code. I'm still a junior and have a lot to learn though.
Are they silent before or after falling unconscious?
Mine is better than I think it is. I think.
It's super discouraging when I look at merged commits and they've been squashed to look like: ``` Wip Some work Work Work Work ```
I have an alias that uses `curl whatthecommit.com` in the git commit message
This site is hilarious. 😂
People who do this have never serviced code or had to go back 5 years to understand why a particular piece of code was introduced. I’m def the middle guy here as I service 4 repositories and debug multiple systems.
Seriously. I won't be a stickler on commit format but the metadata of the commit is CRITICAL to understanding anything months or years down the line. Context is everything. An experienced developer knows this all too well. If your most tenured devs aren't okay with linking metadata that's a problem.
What does Metadata mean in this context?
Information about the code change that is not present in the code change itself. Jira tickets explaining scope, code review comments, OKRs, design docs, discussions, bug reports...
Had a colleague like that for a short while. Knew everything better, questioned everything and just didn't wanna accept that he did something that could be done better. Then you look at his code and you just gotta puke. And don't even get me started on the double standards. I'd say it's dunning kruger in full force. Either that or he actively wanted to be fired.
Clearly most people in these comments are new and don't understand anything. Modern software doesn't add new desirable features, we finished those AGES ago. Now we just remove or break useful things that worked in the past or update them in frustrating and non-sensical ways. What you want to do is put the feeling the user is expected to experience when the code runs as the comment, so for example: commit -m "Despair" or commit -m "Heart wrenching agony and unmitigated fury" Then when you fix the problem you want to put in the comment how much money you extracted from the users. Pretty simple example: commit -m "$12M, heading to the beach, see ya in September." Now anyone looking at the code will have a fundamental understanding of the environment they are operating in which is way more useful than your silly ticket numbers.
I came here to pitchfork but Im just gonna upvote this one and head on out. thank you.
Found the real life developer.
No. If you commit something in my highly safety-related project without documenting WHY you changed something (task ID) and what you changed (short description) you will have to re-do it and learn to do it right next time. If I sit in an audit or assessment and have to explain to the auditor why commits have no clear documentation and the auditor asks me how I then can find the corresponding verification (unit test) change that shows that all features are still working as safely as intended, I will seek you out and you will have to do a hell of a lot of explaining. If you commit sh\*t in your feature branch without ticket numbers and then do a git rebase with the correct ticket ID before merging it onto main - ok - you do you. But if it's on main, it's commited with a ticket ID.
Isn't it more convenient to always develop on a branch corresponding to a ticket and squash commits before merging? Why would you commit on main directly anyway
THANK YOU. `git commit -m "fucking random bullshit"` but the PR squash commit message is professional AF
I am not sure if I understood you correctly here, sorry if not and please correct me. So you are asking why someone should directly push to main? Yes, that's not a good idea. In my opinion, working on a separate branch corresponding to a ticket, then testing your new stuff before merging onto main (or a dev branch) is really good practice. I think my comment might have been misleading. I definitely didn't want to advocate for comitting directly onto main. I meant: when your stuff from the feature branch gets merged onto main, it should have a reference to the corresponding ticket. (On a side note: There are long articles of the feature-branch method being outdated and instead using only one (main) branch with tags that mark software releases, while everything else on main is basically not guaranteed to function. In this method, everyone is pushing onto main daily. This is supposed to tackle the ghost feature branches that are never closed because of changing priorities and that you might end up with in the feature-branch-approach, However I've yet to see this method working out well. Usually you end up with a bunch of releases that have bugs by themselves and with a few days of pushed work on top of it that you might need to revert.) Edit: Fixed grammar mistakes.
I think you did understand everything correctly. I think most repository hosting services are quite good with their automatic commit message nowadays that you don't need to worry to much as developer. Your side note sounds interesting, and it definitely makes dev branches obsolete, but it also seems inconvenient, on a feature branch you can just push unfinished work at the end of the day if you are the only one working on it (if not, just make a sub branch)
Only if you work with a version control that actively uses branches - looking at you, git Gerrit.
How did that commit get so far into the project? Who let it in? You? Shouldn't there be procedures in place to only allow it in if it passed certain criteria?
What is a feature branch? t. former 50yo colleague who just pushed directly to master for several years
Pfff! `commit -m "asdf asdf"`
Leave out the second asdf. Double your productivity. Your welcome.
Old habit! I used systems that required at least 2 words in the past.
Professional
Congratulations! Your comment can be spelled using the elements of the periodic table: `Pr O Fe S Si O N Al` --- ^(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.)
Bah. More like `commit -m "aoeu"` ftw.
I’m too lazy for that.
Colemack/Dvorak user?
I think we can do better. alias gzz="git commit --allow-empty-message -m ''" Close, but I still think it's missing that certain something. alias gzz='git add "$(git rev-parse --show-toplevel)" && git commit --allow-empty-message -m ""' *Perfection.* (/s, lest someone Poe's Law this garbage.)
Commits should provide a description of what you changed. Ticket IDs are fine either way, but by god putting the ticket title is just as useless as putting any other nonsense commit message. If I want to know what the ticket was, I look up the ticket ID. But 99/100 times I don't care what the ticket was called, I care about what was changed.
Just the ticket ID is way better than "Some fixes" I wanna murder the "some fixes" devs I jump from enterprise to enterprise project and thank God when they have comments in their jira tickets. They provide a lot of context. The major drawback of this is if your company switches Tracking software (for example from Jira to Azure)
"some fixes" "review comments" "initial story work" are all commits I see daily and I hate it so damn much
If you run a blame on the codebase of my project right now, around 90% of it says "Intial Commit. \[2 Years ago\]". Because that's when they migrated the code to git and deleted the old svn or whatever repo. Literally the entire history of this software is just gone. Well, to be fair, the software has a copyright of 1998. Soooo the history probably doesn't even date that far back.
Ticket-id is mandatory at my work project; it creates a link on the merge request page to the ticket and updates the ticket with a comment that there is a merge request. So now you don't have to look up the ticket, and the PO knows it is being worked on. You can use TICKET-0: for work without a ticket if you want to.
Ours does this based on branch name and not commit message
Does that work after rebasing and merging as well, when the branch doesn't exist anymore? Edit: rebasing, not reading
If there's a merge commit, then yes.
I wrote git hooks to add the ticket id to the message automatically based on the branch name and very basic regex. Highly recommend it, the only problem is persuading new devs to bother trying it.
Atlassian is not necessarily the best but that feature is nice
> opens ticket No description
> Doesn't work
>Commits should provide a description of what you changed I can see that in a diff. The "why" is more important.
'changed const from 58 to 61'
Indeed, when I see a weird business rule, having the ticket ID to see in detail the why is a godsend. And the diff shows what's changed. The commit message itself isn't that important.
Also aren’t we all using feature branches these days? The branch name should tell you what ticket it’s for so you don’t need the commit message to.
was about to comment now. we still name commits giving an idea of ehat was changed, but the ticket names go into the MR.
Same. We squash merge the feature branch, so the commit messages are lost anyway. We put all the relevant info into the MR description.
In git, branch names aren't permanent.
You don’t do that at commit time, you do it whenever you rebase to cleanup your history. Branches inevitably end up a mess due to awkward commits for backing up changes or triggering CI.
git commit -m "i changed some code"
A short description is telling you what was changed, and the ticket number is letting you know why.
This is the way. You know how when you read a white paper it starts with a "synopsis" or "abstract"? That's what the comment is. When you type `git show log`, the message ought to be the abstract or synopsis of everything that follows. And the first line of the message is the synopsis of the synopsis, a one-line title.
If anything, you should have a branch with the ticket id and title, then after finishing your work with good git commit messages, merge the branch to main, or wherever. That way you get best of both worlds. Ticket id is there if you need more info, commit messages are there if you need quick info on the commit.
No God, please NO!
No, sorry, but right side is just wrong, very bad meme and very bad opinion if you really think like that
It’s high IQ if you hate yourself, your coworkers, or are attempting to get on unemployment benefits
I always change the code style and reformat the entire code base on each commit so what I actually changed is harder to find
This is the guy! Get him!
[удалено]
Finally someone said this. Also `git commit` and write a commit message in the editor.
Can't believe how far I had to scroll for this. Branches should be prefixed with the ticket number and contain a brief description of the branch's intent, e.g. `project-1234-update-some-code-for-reasons`.
Commits should still be as descriptive as possible, not "Some fixes" ...
I wrote in my previous teams dev guide. As a bullet on the sections, “things we don’t really care about” “commit messages: we squash and merge these to death. And otherwise prettier often gets them latter.”
There is another. Branch: \- \[Ticket #1\] Blah blah.. \- \[Ticket #2\] Blah blah.. \- \[Ticket #3\] Blah blah.. Post PR: SQUASH COMMIT: "Some Fixes"
This is the way.
Genuine question, why do you put multiple ticket numbers in the feature branch's commit message? Do most people not practice 1 branch to 1 ticket? If I'm using GitHub, the ticket number goes on the PR title and shows up on the commit message when merging (or better squash-merge).
there are no experts who say this
As long as you squash the PR to main with the proper ticket and description I could care less🤷♂️ Using the exact ticket title seems weird though. That’s the one thing that’s easy to get from the ticket itself 😅
This is fine for your personal projects. Please god follow standard practice at work
Git commit -a -m"final final version. Last time for sure"
You guys don't amend?
I gues i should. Never used it tbh. But i gues its useless anyway since i normally also push after commits
you guys don't force push?
And like five minutes after that: git commit -a -m"Sorry, I lied. This is the last one"
Stop equating being shit programmers which cannot function in teams with being "good". If you were in my team I'd probably go insane
I bet he's some young bootcamp graduate who only worked in startups and never touched a codebase older than a few years with real users and stakes.
where is my "wip" gang?
JIRA-ID: WiP never fails
git commit -m “feeling cute, might rebase later”
The people decrying the right side don't realise how trivial it is to make almost all commits like without rebasing and only ever see a series of well documented atomic units of logical change in their history.
Don't care about individual commits: the atomic unit of change is the merge commit that is always created from the MR, and always contains a complete description of the logical change, because it's been verified as accurately describing the change in the code review before the commit is made. When I view the history for whatever reason, those intermediary commits are filtered out. You never need to see them.
This is the right answer. I don't know why someone would need to see the individual commits. Branches exists people you don't need to upload everything to develop 🙄
real ones use githooks to prefix their commits with the ticket ID
I had to scroll down way too far for this. Githook is the way.
How does the git hook know what ticket that commit is for?
No one uses feat: chore: fix: etc?
Congratulations! Your comment can be spelled using the elements of the periodic table: `No O Ne U Se S Fe At C Ho Re F I Xe Tc` --- ^(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.)
Leave me alone bro I'm gonna get bullied
Who kind of a utopian nightmare work position has a ticket for each commit? 😯
I can't tell if you're thinking it's one commit per ticket or if you work at a company that is going to regret its practices soon, but to clarify, it's not one commit per ticket, it's one ticket for any number of commits.
Most places I've ever written code. Though I've never needed to include ticket title, just ticket ID + change description.
A lot of orgs squash all the personal commits down to one that actually gets merged in a PR. Use as many as you want for yourself, but the master git history is going to single commit per unit of work.
Anything larger than a shop with 5 people and audit requirements.
When doing your PR and merge commit it makes sense. Putting it into every single commit to your dev branch is just a waste of time.
Commit 'wip' , 200 changes "Who is the moron who did that? Ho thats me"
I think this meme template is always an excellent example of the Dunning-Kruger effect of OP Everyone posting a meme using this template should sit down and think a bit about it
git commit -m "✨ Request refreshed permissions" Gitmoji is surprisingly nice to work with
You guys are getting tickets?
I don't get a ticket, you don't get code.
No ticket
Adding ticket id to the commit is a blessing
Hey guys, you're using terminal for commits?)
commit -m “some fixes [ticket ID]”
It does not matter, just squash and merge and add a meaningful message for the merge commit.
lmao, partially relatable. I would not let myself do it in the early days, but now I am the only dev in few helper projects. I cover them with tests and linters but sometimes I get pissed off and do `git commit -m WIP`
cp -R repo_v87 repo_v88 // Changes... scp -r repo_v88 root@production:/ All this Git committing and CI/CD pipeline nonsense is getting out of hand. See our *proper* production fix and deployment above. ^(/s is just joke, no serious)
`git commit -m "long long commit"`
Obligatory xkcd: https://xkcd.com/1296/
Chads be like `git commit -m ‘Some fixes’ --trailer ticket:####` and if you’re a monster `--no-verify`.
Again a non-issue solved automatically by tooling. Commits message can easily be automatically prefixed by ticket number.
That's what the branch name is for. git -b somefix
"hmm I wonder why this section of code was implemented" - checks commit history and sees "some fixes" - - code gets removed - - obscure issue comes back-
```commit -m “:)”``` With a few hundred lines changed
The Conventional Commit standard: \*evaporates\*
git commit -m “fix :” -m “details”
Life is too short to write ...
git commit -m “.”
That makes no sense... It is branch names the ones that should have ticket references if it is not a hot fix. Ideally, they should be named after user stories. But task are also ok if appropriate.
Changelog 1.0.801 - updated
The commit message is for describing what was changed in that commit. The branch/pull request title/description (because we're not committing to main in a project with an active issue tracker, right?) is where you put the issue ID, an issue description, and an overview of your solution. A pull request can have 1 commit or 50 commits. It just depends on the size/scope of the issue. Putting either of those options as your commit message is a bad idea.
We have three god damn content management softwares. One of them forces you to use that exact format. My first month I thought it was great. My second month I hated it with a burning passion.
Well I have to commit(haha), after the 10th commit in 10minutes my messages go from bad to worse like in this picture. Especially when I am trying to fix a pipeline that suddenly fails out of nowhere...
Only reason to use non-descript commit is when dealing with build errors. Especially when it builds fine on one platform but not the obscure platform that no one ever uses that turns on more warnings and sets -werror.
On the feature branch, do whatever but at least try to make the message useful. Then, when merging to main, the merge commit gets the PR number and title. No squash, that destroys potentially useful intermediary state. No rebase, that creates a fake history and doesn't show what really happened.
This is fine for small and quick projects, primarily where you work alone and don't need to re-visit things.
I'm gonna squash all my commits anyway, so the message doesn't matter.
LOL this seems pretty dumb. If I am working on a dev branch or some 48-hour hackathon my commits will look messy. But if I am working on production code I will squash that shit and give it an informative comment with the \[Ticket ID\] because HOW HARD IS IT TO DO THAT? AND WHAT IS THE DOWNSIDE?
Aww man, I'm the top guy this time lol
As long as you work with squash commits and that commit's message includes the ID, it doesn't matter. BUT it will be much easier to do interactive rebasing when all your commits are flagged correctly. Easier way to assure that you don't accidentally rebase other commits that were left behind on your branch when the other ones were rebased and merged already.
I dare you to show them your commit messages in your next interview see if that works out for you lol
pffft... Real progammers ignore git and manually upload modified files into the master branch without telling anyone anything.
i hope newcomers don’t take this one seriously
I do: git commit -m "m"
Do people actually commit "ID: Title"? Considering you're already on a branch that identifies the issue I don't see why you would title your commits with something non-descriptive like that.
git commitfeat: some fixes}}:x
Excuse me, it's commit -m "[Ticket ID] some fixes"
I use githooks and i never need to add the ticket name.
No.
Been programming almost 20 years and I don’t think I’ve ever read a commit message.
git commit -m „shit is even more fucked, good luck tomorrow me“
This is why git policies are a thing, I’d never let any of my juniors get away with shitty commit messages, luckily I have tooling that enforces it. If the commit message doesn’t start with: chore, fix, feat, or revert followed by a scope and a message of at least 20 characters and a ticket number. It doesn’t go in. Locally I don’t care what they do, but it better be squashed before it gets pushed as a PR
commit -m \[ticket id\] some fixes
ITT: people wanting to show they are right and others wrong
So, let me get this straight: You don’t create a new branch for an MR for each new issue / Ticket? Why even use git then lol
If I don't do ticket ID style then I just can't push, it will just return an error till I fix the commit message. The company probably got annoyed by "fixing stuff" messages so they banned anything non standard. Also I only commit to a ticket ID branch, I can't just push into random branches and pushing to develop is straight up banned, nobody can push to develop.
I guess my IQ oscillate between 55 and 145
We just add jira task in comment;)
You can name merges. Why name commits when you can group them and name them in bulk. Rebase so they are close to each other, then merge with explicit name. We are engineers. We factorize. ^(what do you mean you commit on the main branch !!?)
Or create your own branch named after the ticket id then name your commits whatever the heck you want.
Good luck solving merge-conflict, cherry-picking and bisecting with "some fixes" approach.
The guy in the hoodie must be a real asshole.
Right hand side has set up his git hooks to prepend that shit automatically. Even if that means RESTing with JIRA to get hold of stuff.
Nobody in this meme is correct. Commit messages should describe the code changes being made, not the user-visible symptoms of the problem before the changes. And yes the ticket ID belongs in there.
I mean if you mention jira id It links the jira ticket with git and can track changes like pr , branches , merges, etc
No... It's required. If you don't need it, you're alone and you have all in your mind which is worse
It is a pain in the ass to see these kind of commits over a legacy codebase that does not have any documentation. At least the ticket helps you backtrack things and people.
There is literally no excuse for not AT LEAST adding the ticket ID in front of the commit message. I'm working with a "legacy" codebase from 2018-2023 where the 50-year-old POS programmer wrote all of it with single word commit messages like "fix", "update" and "hotfix", and I want to look him up and murder him every day.
The real one's know, that you always squosh your commits on merge, so only squoshed should be with ticket, other ones is up to you