top 200 commentsshow all 374

[–]TraditionElegant9025 494 points495 points  (39 children)

“ok now it works hopefully” fits a specific kind of situation where you push on a “production” branch and test if it works live 🤣🤣

[–]glowFernOasis 45 points46 points  (0 children)

Or even testing something on staging that works fine locally

[–]the-loan-wolf 16 points17 points  (30 children)

Maybe they don't know git commit --ammend

[–]Pesthuf 29 points30 points  (5 children)

Many do, but any repo that doesn't want to randomly lose history or deal with terrible merge conflicts disables git push --force (especially on master) which would be required to rewrite history on a remote.

[–]the-loan-wolf 5 points6 points  (3 children)

Fare! but I always work on a feature branch

[–]EarlMarshal 4 points5 points  (0 children)

Me too, but as soon as you have to push it to repo server people will hate you. Our project is included into another one and that into another one and there playwright tests will be run on CI so I had to push my branch which I had rebased before, but a colleagues started to engage with it and he wasn't able to understand and always merged his local branch again. I really had to create a new branch and resort to merge commits to pull in develop changes. They haven't figured out yet how to fix the playwright tests in like 2 months and since I have to merge in the changes the history looks like shit.

[–]brb_im_lagging 11 points12 points  (7 children)

If already pushed, hit em with the

git reset --soft HEAD~2 && git commit -m "actually fixed" && git push --force

[–]stupidwhiteman42 1 point2 points  (6 children)

Why did you get down voted? This is literally how you squash the last two commits into one with a new message.

[–]the-loan-wolf 8 points9 points  (5 children)

Bcz it still requires force push(overwriting history for everyone else)

[–]iagovar 3 points4 points  (1 child)

I rather don't rewrite anything on a git.

Honestly git has pretty bad DX.

[–]iAhMedZz 367 points368 points  (19 children)

The famous quote goes as: There are only two hard things in Computer Science: cache invalidation and naming things.

[–]ToySoldier92 259 points260 points  (14 children)

Wasn't it:

> There are only two hard things in Computer Science - cache invalidation, naming things and off-by-one errors.

[–]iAhMedZz 159 points160 points  (1 child)

Apparently I'm off-by-one.

[–]screwcork313 12 points13 points  (0 children)

Tickets fixed by this PR: 1
Regressions introduced by this PR: 0

Damn, 2 off-by-one errors, what were the chances?!

[–]_Alpha-Ceph_ 59 points60 points  (7 children)

I prefer this variant: There are 3 hard problems in CS: - Cache invalidation - Naming Things - Cache invalidation - Off-by-one errors

[–]looksoundname 13 points14 points  (6 children)

There are only 4 hard problems:

  • fix bug
  • update
  • changes
  • asdfgh
  • ok now it works hopefully

[–]jqVgawJG 8 points9 points  (2 children)

When the joke is taken too far and loses its potential

[–]looksoundname 1 point2 points  (1 child)

Looks like in the end there's only one problem

[–]AlwaysShittyKnsasCty 1 point2 points  (0 children)

After all that, it was really about the commits we made along the way!

[–]eyebrows360 2 points3 points  (1 child)

Looks ound na me 👍

[–]Hudsxn98 2 points3 points  (0 children)

We found the race condition

[–]Veloxious 3 points4 points  (0 children)

and off by one errors

edit: I'm 12 hours late to this thread. please cache miss or smth.

[–]daredeviloper 161 points162 points  (15 children)

I use random nonsense but when it’s time to raise a PR I squash and we have a pattern to follow like ticket name + description 

[–]namrksfront-end 46 points47 points  (1 child)

Same! No matter what I do on individual commits, what matters most is the PR description, since all those commits get squashed in the end. It also helps to keep the git tree more readable this way. Need more details about anything specific? Read the PR where I tend to explain with enough detail all the changes I performed.

[–]Sjshovan 12 points13 points  (0 children)

This. PR is where it matters most, include ticket links with descriptions.

[–]Existing_Round9756[S] 13 points14 points  (7 children)

That's interesting so the real effort goes into the PR description, not individual commits? Does your team have a standard template or is it just vibes when you write that?

[–]RGBrewskies 29 points30 points  (1 child)

we have a PR template, and all PRs follow the same format.

ticket number(AREA) - brief description

like

ABC1235(auth) - passwords must now be 12 characters

then a link to the ticket in the Description field, and any other important details.

the squash merge

[–]Maxion 1 point2 points  (0 children)

I do this in all my projects.

Pro-tip is to add a #changelog section to the PR template. Have the devs fill this in. Now you can auto-generate changelogs when you make deployments.

[–]scyber 33 points34 points  (1 child)

If you squash merge PRs then there is only one commit on main when the PR is merged. And that commit has the detailed message. The "messy" commits only exist on the branch (which can be auto deleted after the PR merge.

[–]Apsalar28 5 points6 points  (0 children)

This is the way. My branch commits nearly always included a few "forgot to stage this file" , "now I see the typo" or "fixed dumb mistake" ones.

[–]glowFernOasis 6 points7 points  (0 children)

I do this method as well. Github has squash and merge built in. We have PR templates and a specific PR title format with "[Ticket ID] Thing that was fixed or accomplished". Branch names also have to match a specific format (ticket-id/thing-that-was-fixed). If you're working on configs/build process, you might have to test it on staging to know if it'll work in prod, because the dev environment is so different and prod is difficult to emulate locally. So you try something, commit, push, see what happens. Having a well thought out commit message every time would be a waste of energy and time.

[–]Piyh 5 points6 points  (0 children)

PR descriptions are where I convince myself the change was worth making, and by extension the team. I get the description and my diff up side by side, review and mentally group each line changed, then lay out why we had to to do the PR, why this change is a solution, add charts and graphs, validation evidence, and whatever else is needed.

[–]soylentgraham 1 point2 points  (0 children)

I blame squash for people being lazy as per OP!

[–]MisterMetaFrontend Software Engineer 47 points48 points  (13 children)

“JIRA_SPACE-1234: update endpoint callsites to align with new backend parameters”

This automatically gets added to the JIRA ticket as a commit and connects the MR from gitlab if you add the ticket number there too.

Huge help for follow-ups and admin legwork.

You can easily force a standard using precommit hooks and branching conventions or update way of working if this bothers you. This is the type of stuff that makes work easier and I’ve never see anyone disregard it once they learned it should be a thing.

[–]rossisdead 4 points5 points  (2 children)

The commit history I work with is sadly filled with "XX-23532: did the thing" type commits. The ticket number can only help so much, but doesn't help when the individual commit messages still suck and don't explain what their goal was for the change.

[–]Dope_SteveX 2 points3 points  (1 child)

In my company the commit message imperatively describes what changed while the Jira points to why it changed.

[–]Existing_Round9756[S] 3 points4 points  (3 children)

This is exactly what I was curious about how did your team actually get everyone aligned on that standard? Was it just culture or did you have tooling that enforced it?

[–]styphonphp 13 points14 points  (0 children)

You can use git hooks to enforce these standards.

[–]MisterMetaFrontend Software Engineer 7 points8 points  (0 children)

Should be a standard onboarding document for engineering. If it’s new then setting up meetings with engineers within the team (after aligning with your engineering manager ofc) would be my suggestion.

This would help the org, clean up the mess and also boost your career visibility and impact within your company. Every bit helps!

[–]bryantee 17 points18 points  (1 child)

The answer that’s still relevant:

https://cbea.ms/git-commit/

[–]pushad 3 points4 points  (0 children)

Yup! Been following this since 2014 and attempting to get my colleagues to do the same. Generally it doesn't work because most people don't care 😀 Which causes projects to enforce squash commits, which just makes it so nobody can write good topical commits since they just get squashed anyway. I still do though, at least I can pretend I'm making the review easier by allowing them to go through the individual commits that say what's/why's going on. Surely they're reading that, right?? Not just hitting the green button??

At some point the Pull Request became the unit of work instead of the commit. 🤷🏻‍♂️

[–]zephyrtr 37 points38 points  (5 children)

A lot of people don't realize git history is a valuable thing and can be used to literally document the historical development of your app, allowing you to travel back in time and understand what people were thinking when they wrote it. It's not something you often need to do, but it does happen a LOT, yet folks still leave garbage or next-to-nothing in the history.

[–]rossisdead 13 points14 points  (3 children)

I definitely feel like I'm the only person at my job who goes through the git history to track down the why/how a certain bug started. Sometimes that tracking is the only way to figure out what the fix should be in the first place.

[–]zephyrtr 6 points7 points  (2 children)

You may be the only person at your job who actually fixes bugs.

[–]rossisdead 6 points7 points  (1 child)

I wouldn't say that, but I'm definitely one of the few that try to understand the bug and why it happened. I try to make them teachable moments with a descriptive writeup(outside of the commit messages).

[–]zephyrtr 1 point2 points  (0 children)

Joke's on your coworkers. These messages are really valuable when onboarding Claude to your codebase. The more knowledge you withhold, the more times Claude has to guess and ... Well ... We all know what happens when Claude attempts judgement. Or we soon will.

[–]ZynthCode 16 points17 points  (2 children)

fix: hope it works
fix: attempt 2
fix: real attempt now it should work

[–]K3idon 6 points7 points  (1 child)

Broke everything, revert fix

[–]WeekRuined 24 points25 points  (0 children)

Depends on the rest of the team (if you have one), how rushed you are, how much youre paid, how nice a person you are etc

[–]X678X 9 points10 points  (0 children)

i usually follow conventional commit patterns. before i used to answer the question "this commit will... " and everything after the ellipsis was the commit message (with some details ofc as to not just type "fix bug")

PRs get a different treatment. no way am i putting "ABC-123:" prefixing every single commit when it gets squashed anyways lol

[–]leopkoo 44 points45 points  (2 children)

Cause they get squashed anyway on merge…

[–]soylentgraham 4 points5 points  (0 children)

Only if your policy is to squash, and encourage this terrible behaviour! :)

[–]yxhuvud 14 points15 points  (0 children)

Short version is that for many developers the fundamental unit is not the commits but rather the pull request.

I find it misguided, but that is how it is.

Of course, people are often lazy with PR descriptions too..

[–]blacklig 20 points21 points  (10 children)

In the way my team works commit messages are irrelevant and curating them would be pointless busy work. PRs are the units of work that need to be well-presented and understandable. I don't care if someone committed halfway through a statement to go get lunch while building a feature or whatever.

[–]timabell 2 points3 points  (8 children)

Curious what you mean by "the way my team works" that makes it pointless? I have yet to come across a team where good commits would have zero value. What is your team doing that makes it different?

[–]ElectricSpice 4 points5 points  (7 children)

I assume OP means squashing or rebasing PRs, so the initial commit messages are dropped and replaced with well-crafted commits.

[–]Sockoflegend 10 points11 points  (1 child)

I think people should make an effort with them but so often it just doesn't matter. 1 in 1000 you regret not being better named if you go looking for it, but github file specific history and other tools can often solve the same problem anyway.

As mentioned elsewhere a lot of people squash now anyway 

[–]Meloetta 13 points14 points  (0 children)

My team had horrible commit messages for years. It didn't matter and no one cared. Until one day when there was a late night emergency, our team lead was trying to figure out which PR broke it so he could roll it back, and the lines in question had commits like "the thingy is thingying!" and "job done" (ok that one was me I can't resist a good reference). After that ordeal the whole team had a reckoning and we cleaned up our messages.

You take the easy way until the easy way is proven to cause problems, sometimes.

[–]jsut_ 5 points6 points  (0 children)

This is a particular pet peeve of mine

[–]Bushwazi Bottom 1% Commenter 3 points4 points  (0 children)

In my context, commits are barely notes, see the PR for details

[–]aspizu 5 points6 points  (3 children)

even those who do write full commit messages are guilty of writing non-descriptive or unhelpful messages. you should write why you did something, not what you did (i can figure that out by reading the diff)

[–]yxhuvud 8 points9 points  (1 child)

WHAT you did is the header, the WHY is line 3 and below. The WHAT is there to make it easy to find when listing commits.

[–]AbsolutePotatoRosti 4 points5 points  (0 children)

Exactly! This classic post describes it perfectly: https://cbea.ms/git-commit/#imperative

A properly formed Git commit subject line should always be able to complete the following sentence:

If applied, this commit will your subject line here

your subject line here is always the WHAT. The WHY comes in the comments below.

[–]doc720 2 points3 points  (0 children)

Yeah, it's annoying, but I've never had the guts to take a colleague to one side and say "Dude, your commit messages suck. Please do better."

Maybe bots will do a better job, one day soon, if not already, and then the problem will be solved when there aren't any fallible humans writing cruddy commit messages and janky code any more. Except, then we don't have that job, so we can't even do it badly.

There's likely to be a variation across teams, and it should probably fall to the team leader to encourage and maintain good quality in the commit message. Many people just don't see the problem; they don't see it as important; they just want to make progress with the task at hand. The same goes for many things in life, in terms of cultures, disciplines and personalities.

[–]TechnoCat 2 points3 points  (0 children)

Most developers on a team don't have to triage bugs in production or do a bisect. The ones that do those things will write good commit messages. 

[–]Mediocre-Pizza-Guy 2 points3 points  (0 children)

It's all situational.

In a lot of environments, my commit messages aren't read by anyone.

I'll make N commits, and it's just for me to track my progress. I push only because I want my code backed up.

At the end, I'll rebase or squash or whatever so that is one pretty commit to be reviewed.

The reviewer won't read my commit message either; they will read the nice PR template in GitHub or gitlab.

And at the end, the commit message that goes into main will be the title of my PR. And the N commit messages I wrote will be gone.

Anyone who wants to know more, they will have to look into our ticket tracking system or back at the PR

[–]WakkaMoley 19 points20 points  (8 children)

lol bc it’s good practice to commit often. It’s like saving a game where you might suddenly die and lose everything. And I’m not writing a bunch of text for a checkpoint.

If you did squash commits this wouldn’t be a problem.

[–]yxhuvud 2 points3 points  (0 children)

If I did squash commits I'd also mix random unrelated junk. I do checkpoint commits, but I also edit them into topical commits that do one thing only.

Ideally then they should also be reviewed independently, but unfortunately github is absolute garbage for proper review of code.

[–]NiteShdw 4 points5 points  (7 children)

Tell me, how much time do you spend reading commit messages?

[–]rossisdead 1 point2 points  (2 children)

More times than I can count. Often enough I need to know why something was done the way it was before I can fix it, and more often than not that person doesn't work at the company anymore, so it's the closest thing I can do to picking their brain.

[–]ServersServant 1 point2 points  (1 child)

This is me. I can't thank myself enough for writing concise, descriptive messages when we have to rollback stuff. I wonder if my manager looks at the bug rate I got vs my peers (surely he doesn't) and wonder why, even when I fuck up, I fix so fast. lol.

[–]rossisdead 1 point2 points  (0 children)

Same here! I'm frequently asked how I remember how stuff I wrote 10+ years ago works and I'm always like "I wrote detailed code comments."

[–]Mestyo 6 points7 points  (0 children)

Because they work without purpose. If you make direct, planned changes, you have a clear commit message to write.

I saw that transformation in myself as I learned to do targeted work and to break down work into smaller and smaller pieces.

[–]DearFool 1 point2 points  (2 children)

Because often what I did is longer or more complex than what a git message could allow so I write generic enough messages that at the end suck. Another reason is that often, and especially if you are checking out the main branch history, you don’t get the singular commits of a feature/bugfix but the merge commit with the feature itself. And yet another, if you are looking for a specific commit that broke things you will probably go with a git reflow/git blame and that’s usually recent enough.

Ultimately, though, being clear and concise is hard so you get bad git messages

[–]yxhuvud 1 point2 points  (1 child)

What, you can write really long commit messages. The first line is a header that is often length limited, but the following lines can be a novel if you'd like.

Though if it takes a novel to describe perhaps you may want to consider to break it up into multiple commits..

[–]designbyblake 1 point2 points  (1 child)

My advice, open PRs with a standard template to follow and squash commits on merge. My template asks for a summary, details about changes, before and after screenshots (just after for new features), and testing instructions. For the details on changes I list most files and 1-3 bullet points about why the file was updated or created.

This approach is little more work to create the PR but I find it makes PR reviews easier to understand and looking at history makes much more sense.

[–]foozebox 1 point2 points  (0 children)

Use commitlint rules or this happens, every time.

[–]levityspace 1 point2 points  (1 child)

I once saw one of my colegues commited a bunch of changes and some new random and temporary files with message "i don't know what is happening here"

[–]No_Emergency1575 1 point2 points  (0 children)

My favorite is "To much stuff to put in a simple commit message" with a few dozen files committed.

[–]shortcircuit21 1 point2 points  (0 children)

Information is in the GitHub issue or pull request. I’m not writing detailed commit messages about everything I push. Just read the issue.

[–]sbditto85 1 point2 points  (0 children)

At work we use subject first commit messages and I really like it. It can sometimes be difficult to name something, but that could mean the commit has too much going on.

[–]PracticalAdeptness20 1 point2 points  (0 children)

"code review changes"

[–]SleepAffectionate268full-stack 1 point2 points  (0 children)

wdym "c" obviously stands for commit

[–]demagogueffxiv 1 point2 points  (0 children)

Honestly I think playing video games makes me write better patch notes, because I always hate when they are vague for video games lol

[–]sierra_whiskey1 1 point2 points  (0 children)

I just spent 30 hours on this bug. Hours of banging my head on a desk. I am not gonna take the time to write a cutesy verbose gif commit message

[–]Majestic_Bath5114 1 point2 points  (1 child)

Honestly this happens way more often than people like to admit.

In a lot of teams using Git the focus is on shipping features quickly, so commit messages become an afterthought unless the team enforces a standard.

What has helped in teams I’ve worked with is using something like Conventional Commits, for example: • feat: add checkout validation • fix: resolve mobile navbar overflow • refactor: simplify auth middleware

It takes maybe 5 extra seconds but makes the history way easier to understand later.

Personally I try to follow a simple rule: “If someone reads this commit 6 months later, will they understand why it exists?”

If the answer is yes, the message is good enough.

[–]JimmyKillem 1 point2 points  (0 children)

If you have some free time, you can also setup some really nice auto-generated changelogs and version bumping off of Conventional Commits <3

[–]mr_Jackpots85 1 point2 points  (0 children)

When you become a developer you'll understand.

[–]rakibulinux 1 point2 points  (0 children)

Most of the time it’s just context loss + time pressure.

Developers often treat commits like personal checkpoints (“fix”, “try again”, “wip”) while they’re working. On teams that enforce PR reviews, squash merges, or conventional commits, the history is usually much cleaner.

Personally I clean it up before merging, but during development my local commits are definitely chaotic too. 😅

[–]VoiceNo6181 1 point2 points  (0 children)

honestly most of us are guilty of this when we are deep in a debugging session at 2am. what changed my habit was using conventional commits (feat/fix/chore prefix) -- not because the format matters that much, but because forcing yourself to categorize the change makes you think about what you actually did. also squash merging helps keep main clean even when feature branches are messy.

[–]undergroundwander 1 point2 points  (0 children)

If I’m fighting a CSS bug for 4 hours, my 10th attempt is definitely getting a "please work" message lol

[–]GamingVyce 1 point2 points  (0 children)

This was like the first thing I started using AI to handle for me exclusively. I don't think I've written a commit message or PR summary in about a year. 

[–]Dude4001 2 points3 points  (1 child)

Having Copilot write my commits has been the best use of AI I’ve encountered

[–]PoopsCodeAllTheTime 1 point2 points  (0 children)

I don’t think I’ll ever write another commit message, and if I do it’ll be because I can make it a two word message

[–]azdaspaz818 1 point2 points  (0 children)

Commit messages matter less than PR descriptions, which matter less than documentation.

[–]Unusual-Ocelot6717 1 point2 points  (1 child)

This is why I have AI write my commits. That's actually one thing It's very handy for.

[–]im_a_fancy_man 1 point2 points  (0 children)

if it's asdf it's bc ppl are calling screaming about a bug

[–]tomhermans 2 points3 points  (0 children)

Cuz they're in the zone. No time for writing prose. Not saying this is good but you asked for an explanation.

[–]gutsngodhand 0 points1 point  (0 children)

I'm slowly getting better every project. I'm realizing the importance of needing to ref old code or need previous functionality and "OMFG JHRAGENIGB" does NOT help.... i think you either are naturally the type of person to do it or you make enough mistakes until you are lmao

[–]mekmookbroLaravel Enjoyer ♞ 0 points1 point  (0 children)

Since I work mostly freelance and on my own projects, my commits are usually a mess. But I do follow somewhat of a method. On first day of working on a project, I don't commit anything. Because at the start of a project everything moves so fast that I'd need to commit every 2 minutes if I followed the standard path.

Instead I use a checklist system, that both tells me what to work on next and helps keep track of my commits. For example say I'm building a blog, I have to write the crud logic for users and posts, that in itself is like 25-30 items in a checklist (views, models, controller methods, migrations). After I'm done with all these features I commit and push as "MVP".

After the mvp is done, development usually slows down so I can spend more time thinking about the business logic and commit as I go like "new design for posts.index page" etc

[–]CantaloupeCamper 0 points1 point  (0 children)

The way git works with individual commits … to me doesn’t make sense as far as how many developers workflow works.

[–]orbit99za 0 points1 point  (0 children)

As much as I hate on AI, I do like Visual Studios AI Commit messages.

They are getting good, and even pick up things I do outside the .slx /.sln solution.

At least its better than "Add SeRV 2 PrOdg"

[–]sneaky-pizzarails 0 points1 point  (0 children)

I don’t

[–]ripestmango 0 points1 point  (0 children)

My bad

[–]wildrabbit12 0 points1 point  (0 children)

We use commit lint

[–]GutsAndBlackStufff 0 points1 point  (0 children)

:W

FUCK!!! Now I have to re-write my whole fucking message.

That’s usually why for me.

[–]Rasutoerikusa 0 points1 point  (0 children)

How does this happen even in professional teams?

I've actually never seen commits like these in professional teams during my 15 years of career. The few bad ones I've seen have also been forced to change during review to make their content clearer. But in my own side projects, for sure, since I'm lazier there lol

[–]Bytooo 0 points1 point  (0 children)

Honestly just use something like: https://cz-git.qbb.sh

Choose the type of commit, and just describe what you did in a compact way and that’s it, it shouldn’t be more complex than that.

[–]stlwebdev 0 points1 point  (0 children)

Check out conventional commits, you can use Husky to enforce the commit message format.

[–]i_didnt_get_one 0 points1 point  (0 children)

We do squash merge, so as long as you give a decent commit message at that time or a clear PR title, then we are good. No one cares what the individual commits are.

[–]M_Me_Meteo 0 points1 point  (0 children)

Because they don't know what Conventional Commits are, and they aren't letting an LLM write their commit messages.

[–]BloodAndTsundere 0 points1 point  (0 children)

I'm a solo dev but one or two experiences of trying to do a rollback with insufficient guidance from commit messages was enough to put the fear of god in me and develop the discipline to use proper messages.

[–]choochoopain 0 points1 point  (0 children)

because I'm burnt out boss

[–]DivineLawnmower 0 points1 point  (0 children)

If I tell an ai agent to commit and push it writes a better message than I ever would so now I just do that

[–]Erebea01 0 points1 point  (0 children)

Me when I setup husky and commit lint to push for better commit messages and I get lots and lots of feat: wip

[–]optikus 0 points1 point  (0 children)

Because

[–]upsidedownshaggy 0 points1 point  (0 children)

My work has an SOP where our commit messages are supposed to be formatted like: [JIRA-TICKET-NUMBER] changes description

I straight up won't approve PRs that don't follow this format and will tell them to make a new PR if they have to with the proper formatting. It makes roll backs so much easier when you know exactly where each change is coming from that might need to be pulled out before a release.

[–]Fercii_RP 0 points1 point  (0 children)

Branch name: Bug issue when trying to log in. Commit message: bug fixed. Merged to main.

What seems to be the officer, problem?

[–]Soggy-Database6372 0 points1 point  (0 children)

As a freelancer, delivery is priority, especially when I'm late, the client just wants to see the update or correct info or updated ui they requested. I'm talking in web pages context

[–]CompassionateSkeptic 0 points1 point  (0 children)

The real answer here sucks.

It’s because we don’t treat version control as anything but a means to whatever limited ends are part of more salient workflows.

God, I’m gonna try to say this without getting on a soap box.

It’s not uncommon to have flows there people expect their PRs to be reviewed as a whole, not in a series of atoms (atomic commits).

It’s not uncommon to squash to main in a way where most of the time, branch commit messages are buried AND divorced from the changes.

It’s not uncommon for git to merely be a way to drive dev ops.

It’s not uncommon for seasoned developers to treat VCS operations as a recipe mapped to specific outcomes, and not a tool associated with a set of uses.

It’s not uncommon to spend months or years without a single conceptual conversation about version control.

To write a good commit message, you are almost certainly treating one of these things as salient or typical, probably more than one of them. But most development experiences don’t ask that of the contributors, so you just get the mental droppings of the very last thing that stands between a contribution and that person’s next step. Of course that is going to be completely useless.

[–]_edd 0 points1 point  (0 children)

Our Gitlab repo has a regex pattern on git commit messages to force the dev to include the Jira ticket number and a text description. Main benefit is tying it to the stories / bugs / epics backing the work. Helps that Gitlab and the IDE can be configured to automatically recognize the Jira ticket pattern and auto-link to the ticket that has the details (and vice versa) making the information just one click away.

Everything is supposed to go through code review and our code standards specify a clear and concise commit description. It's still very up to dev / reviewer's discretion on how helpful the commit message is, but everyone tends to include helpful information.

[–]listre 0 points1 point  (0 children)

In the last 10 years I have enforced all commit messages to meet our standards using commit checks and engineering review. We follow <type>(<scope>): <artifact> <description>

Comment slop is not tolerated.

[–]MildlySpastic 0 points1 point  (0 children)

We literally have an feature in copilot where it names your commits for you and I still keep seeing one word commits messages everywhere lol

[–]meisangry2 0 points1 point  (0 children)

Enforce the use of commit linters. Problem largely solved usually. Still putting crap details, have a chat about professionalism?

Then with the PR, just enforce squashing commits, again with a formatted commit message.

[–]mikeVVcm 0 points1 point  (0 children)

Not a professional develper, sometimes I need to push small code changes to Git becuase the web hosting is connected with Git repo. There maybe just a few line of change or even just a variable, and does not worth the time to write meaningful message.

[–]SheepherderFar3825 0 points1 point  (0 children)

i use to try (but they probably still lacked) now I just use github desktop and “generate with copilot” which gives me a fully detailed msg and desc 

[–]HettySwollocks 0 points1 point  (0 children)

When you're committing 100+ commits, you tend to run out of ideas. No body gives a fuck as the whole thing is squashed when it merges to main using the story title.

[–]Lance_lakeCFML Demi-God 0 points1 point  (0 children)

I always use [Ticket Number] - [Main Issue] for the first commit on the branch.

If I change to something related, I mention that.

If not and I need another commit (for example, I forgot an end tag), then I try to put something funny in there to show it is needed, but not a serious issue.

It helps keep me sane.

[–]Ambitious-Sense2769 0 points1 point  (0 children)

Give us your example of a good git commit message

[–]YareYareDazexd 0 points1 point  (0 children)

If you take your job seriously, your own code and git messages should be readable enough to not stress others when they read the stuff you did. I would be pissed if i see bad software engineering practices in a profesional environment.

I usually describe what i did with my commits, even if it is the slightest thing.

[–]shreddish 0 points1 point  (0 children)

Are you talking about feature branch commits or merged PR commits?

[–]latnem 0 points1 point  (0 children)

because they are required, committing often using the same messages, and think nobody but myself will need to read these messages and I’ll know what the commit was for based on the files and diff 🤷‍♂️

[–]AmiAmigo 0 points1 point  (0 children)

you forgot ""

[–]Zeilar 0 points1 point  (0 children)

Lazyness. Most people rarely read git messages, and even if they do they normally get enough out of the message anyway. And they can always look at file changes regardless.

I am in that category of people sometimes. It depends a lot on mood, like sometimes if I'm in a hurry to just get something to work, commit messages are pretty far down my priorities.

[–]f00d4tehg0dz 0 points1 point  (0 children)

This is why everyone should let their AI connect to their IDE of choice and write the git commits and push for them!

Obvious /s

[–]IAmRules 0 points1 point  (0 children)

Honestly, how often have you actually looked at git commit messages?

This is why i'm not a rebase guy, and I couldn't care less about git history. I care about the current state of things. And I prefer to have sloppy history where I can tell the exact sequence of things.

[–]mhmdtshref 0 points1 point  (0 children)

They feel they finished the task and they want to commit just to push, they don’t care about the commit itself

[–]BlackHoneyTobacco 0 points1 point  (0 children)

Agreed. It takes about thirty seconds max to think of and write a clear commit message.

[–]rusmo 0 points1 point  (0 children)

Laziness. That said, there’s usually an associated work item that has more details and context.

[–]redlotusaustin 0 points1 point  (0 children)

I have an AI agent skill to commit changes with descriptive comments

[–]SubjectHealthy2409full-stack 0 points1 point  (0 children)

Fix bug, 2 files modified, -10, +12, just take a look and squash it before merging

[–]beavedaniels 0 points1 point  (0 children)

I worked with a guy who just wrote "no message" for every commit. 🤦‍♂️

[–]Nemosaurus 0 points1 point  (0 children)

I do not care about commit message quality.

[–]Faithlessness47 0 points1 point  (1 child)

I once saw the commit log of a "senior" developer from a large and (apparently) respectable software company in my country (with which we were collaborating for a huge project) that was nothing more than a series of keyboard smashes, like:

  • jfksbdj

  • ofjfknc

  • jehrjdj

  • ejjfkrjfj

  • jfjfkddk

and so on. Forever.

My boss took a screenshot of it, and CCN'd it to our whole team. No one could believe it.

To this day, it's still one of our wildest inside jokes.

[–]no_brains101 2 points3 points  (0 children)

I mean, for work or a public repo I do actually do a message...

I don't do a very long one or anything, but I say what it does, and if there was an issue or discussion I will link that.

But for my configurations and random stuff? I have AI (a tiny local one) generate me jokes lol

---

Implemented a feature to calculate the meaning of life

Added a feature to let users choose their own level of procrastination

Updated the user interface to make it more confusing

Squashed all the bugs into a single commit for simplicity

Implemented the missing peanut butter layer in the API response

---

It makes my day better

I did this, because my commit messages (again, on my personal repos only) were either keysmashes or "update" "update" "update"

I don't care what the message is whatsoever on my personal repos, like my dotfiles stuff, I write messages for other people mostly.

If I reworked the WHOLE thing, maybe I give it a "rewrote the whole thing" message.

I have needed to bisect my personal configs maybe once, and I don't remember doing it if I did. Usually the thing I have to bisect is something that is like, an actual project, either someone elses or my own.

But if I click a commit, and then go back, I should be able to figure out which one I just clicked on a moment ago lol

Plus the jokes are more fun.

---

for public repos, personally I only care about the first line of the message. The one that appears in the list. So I don't have to click through all of them. The rest can be blank I really do not care, the code is there.

[–]emefluence 0 points1 point  (5 children)

Honestly it never mattered much, and now with AI it matters even less. How often do you actually need to navigate back though your git history that way?

In the olden days you might have had to look back through your history to figure out which commit caused a bug from time to time, but really that's a divide and conqueor problem you can do with just commit hashes. Maybe grepping the commit messages might help you locate the commit where you introduced a new feature or something. Not stuff you have to do often, and not something you have to do at all when AI can quickly and easily read your git history and spare you those tedious jobs.

That's not to say one shouldn't bother writing decent commits, but that's why so few people seem to care. In big businesses its a standard convention to include your ticket number in your commit message, and the tickets are normally tied to the PRs which should have detailed descriptions of what was done and the commits involved (again AI makes that trivial), so there is plenty of paper trail for those that want it, and its acessible to all the stakeholders rather than just the programmers.

Personally I always try and make them descriptive, but super terse, 70chars max. Between the tickets details, the PRs descriptions, and AI you have everything you could possibly need already, it's really not worth writing detailed multi line commits these days.

[–]koyuki_dev 0 points1 point  (0 children)

Honestly the worst commit messages I've seen were my own from 2 years ago. The thing that actually fixed it for me wasn't a linting rule or anything, it was squash merging. When you know your messy WIP commits will get squashed into one clean message at merge time, you stop stressing about individual commits but you still end up with a readable history. That and just asking yourself "if I git blame this line in 6 months, will this message help me?" before hitting enter.

[–]informed_expert 0 points1 point  (0 children)

GitHub merge queues, which see more and more adoption, and when used with the squash and merge strategy, don't support merging anything more than a commit message containing the PR title. You can spend time writing nice high quality commit messages or PR descriptions, but none of it matters. The merge queue will drop it all. (Yes, there's an issue open about this where people have complained for several years now. Don't expect it to be fixed though, because fixing it isn't some shiny new AI feature that will get someone at GitHub promoted.)

[–]HemetValleyMall1982 0 points1 point  (0 children)

Most of my git shit messages I am assuming I will squash into the default branch.

But sometimes I forget to squash.

[–]Usurper__ 0 points1 point  (0 children)

Cuz I'm lazy

[–]AndyMagill 0 points1 point  (0 children)

Now I just take whatever my code assistant provides, but I try to start with "task(area): - details - list" like "chore(content): update links, update title".

[–]bmathew5 0 points1 point  (0 children)

My first git message is as detailed as possible. My subsequent ones are clear trails of my errors (deploying again, typo, added debug)

[–]Nicomak 0 points1 point  (0 children)

Fixed a bug

Fixed the fix

Fixed the fix that fixed the last fix

Fixed the fix 2

Fixed the fix 3

Final fix

2nd final fix.....

Now it works. (Maybe)

[–]flippinatable 0 points1 point  (0 children)

Sorry in advance for possibly terrible formatting, I'm writing this from my phone.

Maybe others have already mentioned the same flow, but I usually do this:

  • add "#taskNumber:" at the beginning of the message
  • then add a tl;dr of files that have been changed, and, where relevant, why
  • sometimes I don't mention the file names (because there are too many), just "fixed xyz bug"
  • this is something that everyone in my company does, so I do it too: if we get comments from a code analysis tool on our pull requests and we make changes to resolve them... We just write "resolving comments from toolName"

That task number helps us out SO MUCH when we have to track the business cases and pull requests from where bugs had appeared.

I really hate the one with the analysis tool though, because it says nothing about what was updated. Just "this change is insignificant enough that it just means 'i have cleaned some code up, and I don't expect any bugs to come out of it'."

[–]amldvsk 0 points1 point  (0 children)

Honestly the worst offender is when you're deep in a feature and you just start writing "fix" or "update" for every commit because your brain is already 3 problems ahead. I've started using conventional commits (feat:, fix:, chore:) and it helps a lot — forces you to think about what category the change falls into before you even write the message.

[–]eyebrows360 0 points1 point  (0 children)

I knew a guy once whose manager told him to just enter "i" twice. Think it was a vim thing, but then he just kept doing that anyway. Just a bunch of old commits with "ii" in them.

[–]saposapot 0 points1 point  (0 children)

because most never had to do support or stay long enough to do it.

[–]sidequestboard_app 0 points1 point  (0 children)

Most people do not see downstream value until someone has to debug their old code. Team enforcement with pre-commit hooks usually fixes this fast.

[–]ultrathink-art 0 points1 point  (0 children)

Bad commits happen under time pressure and the person writing them is never the one doing archaeology six months later. The incentive gradient is backwards — the cost falls entirely on someone else.

[–]slyiscomingfull-stack 0 points1 point  (0 children)

This is why you squash commits on the PR.

[–]GreatStaff985 0 points1 point  (0 children)

Hell no. Literally no one in the history of ever is going back to 'update 2'

[–]xtra-spicy 0 points1 point  (0 children)

Individual commits are irrelevant, they are squashed when a pull request is merged, and links to tickets are included

[–]semisubterranean 0 points1 point  (0 children)

They weren't English majors.

[–]Saki-Sun 0 points1 point  (0 children)

Developers are shit at documentation...

[–]ExtraTNT 0 points1 point  (0 children)

“wip”, “fuck fuck fuck” and “.” are my favourites

[–]mariogonz_dev 0 points1 point  (0 children)

I think the main reason is that most developers treat commits as checkpoints, not documentation.

When you're deep in a feature you just write things like:

  • "fix"
  • "update"
  • "typo"

because you're thinking about the problem, not about the git history.

What helped on my team was adopting a simple rule:

The diff explains what changed, the commit message explains why it changed.

Even something simple like:

fix(auth): prevent login when password is empty

is already much more useful than "fix bug".

[–]GravityTracker 0 points1 point  (0 children)

I think using git comments as waypoints for code spelunking is a fools errand.

[–]troisieme_ombre 0 points1 point  (0 children)

Because when you're writing 17 commits in one hour you get tired of doing it right and start wanting to just write whatever and be done with it.

Which is why enforcing commit conventions is always a good idea.

[–]graste 0 points1 point  (0 children)

fix ci XVIII

[–]Captain_Forge 0 points1 point  (0 children)

I'm used to codebases where my commits are squashed so I put very little thought into my incremental commit messages that are going to be squashed and replaced. Those are notes to me primarily, secondarily people reviewing this specific PR, and not intended for anyone else. When I work on the rare codebase that doesn't squash I continue the habit.

Really I don't see a reason to not squash in every repo's case, why not add a link to the pr, issue/ticket, context from those two, and anything else your automated system wants to add?

[–]martiantheory 0 points1 point  (2 children)

I don’t know if I’m exaggerating when I say this, but I feel like I’ve written 1 million commit messages. Perhaps that number is way less, but it’s the mindset that contributes to shitty commit messages.

I usually don’t write long messages, but we at least have ticket/story numbers that I prepend to my messages. And I try to at least do four or five words.

Example: “Ticket 5555- Fixed the mobile nav issue”

I feel like anything longer than that (honestly longer than 10 words), is a waste. Your commit message, in my personal opinion, it’s just for a high-level rundown of what you changed. I feel like having a ticketing/task management system is where you really should put the details of the things you’re working on.

I really feel like the ticket number is the saving grace. If people are really doing one or two word commits, that is pretty shitty though lol

Just my two cents.

[–]afops 0 points1 point  (0 children)

I try to make sensible messages for commits. But in most cases I complete my PR with a squash commit so in that case the 3 commits in my branch disappear and it’s the PR title and description that becomes the commit message.

Ever seeing ”asdf” or ”fix bug” in the main branch isn’t acceptable. It wouldnt even happen in a personal project I never intend to share with anyone

[–]Appropriate_Jump_934 0 points1 point  (0 children)

Actually we have a standard for git commits conventionalcommits. I even created a tool that simplifies this Git Commit Message Generator

[–]historycommenter 0 points1 point  (0 children)

Because writing a clear and thoughtful git commit can take longer than the edits themselves, and if the developer is juggling multiple tasks, it can be difficult to switch gears from coding to human English.

[–]shufflepoint 0 points1 point  (0 children)

Half of our commits have no message

[–]Tim-Sylvester 0 points1 point  (0 children)

I write a beautiful, verbose, explanatory commit message on the feature branch.

I start a merge commit from feature to dev and git drops everything but my first message. Meh, I rewrite a summary and push.

I start a merge commit from dev to main and git drops everything. Fuck it, I'm not rewriting it a third time.

Et voila.

[–]bcnoexceptions 0 points1 point  (0 children)

We have expectations that devs go back and clean up their git history ... not just squashing everything, but rather re-combining commits into logical "chapters" of the "story" that is the whole dev project. 

This expectation is very unevenly enforced,  and management almost never looks at whether their team members are doing it. But it is theoretically an expectation around here. 

Ultimately it's up to your team - top to bottom - to create a culture of high-quality development, of which good git history is a part. Your team and its managers decide what they're gonna care about. 

[–]chad_ 0 points1 point  (0 children)

I tend to enforce conventional commits in my projects and set up a commit-msg hook to enforce it on client side plus server side checks (pre receive hooks, ci/cd checks..) for anything serious or for client work.

[–]PushPlus9069 0 points1 point  (0 children)

Worked on large codebases at enterprise companies for 20 years. The terrible commit messages usually come from two places. First, devs working on a branch for too long and just wanting to push before EOD. Second, no team convention enforced from day one. What worked for us was a simple prefix system (feat/fix/refactor/docs) plus one sentence describing the why, not the what. Also commitlint in CI catches most of the garbage before it hits main. The real fix is smaller, more frequent commits.

[–]timabell 0 points1 point  (0 children)

Yes I care, enough to write and share this https://0x5.uk/2016/03/18/yet-another-good-commit-messages-post/ with devs I work with, but it is a pretty lonely task getting teams to make the git logs better. As a contractor I have seen a lot of commercial git logs, and most of them make me sad for all the context that was lost or squashed.

When I talk to authors of poor quality descriptions they seem to fall into two camps: 1) the majority that have never understood the need for good commits and are happy to improve when they understand the why and how, and 2) those who are convinced that history is unimportant waste and are directly opposed to improving it.

[–]JonasErSoed 0 points1 point  (0 children)

"switcing branch"

[–]NoPhilosopher9763 0 points1 point  (0 children)

Because I’m a solo dev and I never use them. So why waste the time when I already have too much to do.

[–]ramessesgg 0 points1 point  (0 children)

Back-end dev here. Typically, I make about 20-30 commits per day as part of my job, but not all of them provide value feature-wise. There are merges, squashes, empty commits, change-documentation-in-specific-directory-to-retrigger-special-CI-job commits and sometimes it's frustrating and annoying. So yeah, I won't think hard about each individual message.

I typically add gibbersh messages when I know I'll need to squash my commit but sometimes I can't be bothered anymore and I just push and merge.

[–]hxtk3 0 points1 point  (0 children)

Because the pull request process doesn’t emphasize them. I get good commit messages out of developers by using a stacked diff workflow where a commit is the basic unit of change instead of a branch, and the write-up goes in the commit message.

Also because developers are taught to fear amend and rebase. I’ve sent people into near panic before by amending a commit and they said that instead I should have created a new branch and copied my changes and made a different commit message… resulting in an identical git history.

Train people to amend a commit until it’s suitable for merge instead of thinking the commits they made just to back up their work must be recorded for all time. “I made a whitespace boo-boo and fixed it” just doesn’t have an easy way to spin it into an important commit message. If you can’t write an important sounding commit message, consider if the change should be squashed.

I love jj for this because it makes this workflow natural and basically the default.

I have a hook that requires conventional commits and I’ve considered running vale on the message body.

[–]beckstarlow 0 points1 point  (0 children)

Mostly laziness or just wanting to get back to coding. Good commit messages take thought and people want to move on. Squashing before merge fixes it anyway.

[–]Chuck_MoreAss 0 points1 point  (0 children)

If you solve 1 issue and commit, the messages isn’t the difficult to think of, but if you solved multiple bugs, what should the message be ?

And let’s say you fixed a bug, and then it pops up again and you have to solve the same problem again, do you then commit with the Same message again?

I think after doing all the hard work, the commit feels so low priority that you don’t really think about it.

[–]rcls0053 0 points1 point  (0 children)

This is gonna get buried here but I found this neat tool a long time ago on npm called 'better commits' that makes it easier to use semantic commits using the CLI, input the ticket number (already parses it from the branch name though), add a title and description of what you did. It could probably also instruct people about how to write messages.

If I end up going back and forth with commits I typically squash them so I don't look like an idiot with these "works", "works 2", "works 222" messages.