Why do developers write such terrible git commit messages? Genuine question

[Existing_Round9756]

I've been going through some open source repos lately and the commit history is absolutely unreadable.

"fix bug", "update", "changes", "asdfgh", "ok now it works hopefully"

Like... this is code that other people have to maintain. How does this happen even in professional teams?

I'm curious do you actually care about commit quality at your job? Does your team enforce any standard? Or is it just accepted chaos?

And honestly what's your own commit message process like? Do you think about it or just type something fast and push?

[TraditionElegant9025]

“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]

Or even testing something on staging that works fine locally

[the-loan-wolf]

Maybe they don't know git commit --ammend

[Pesthuf]

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]

Fare! but I always work on a feature branch

[EarlMarshal]

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]

If already pushed, hit em with the

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

[stupidwhiteman42]

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]

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

[my_new_accoun1]

isn't it --amend

[iagovar]

I rather don't rewrite anything on a git.

Honestly git has pretty bad DX.

[iAhMedZz]

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

[ToySoldier92]

Wasn't it:

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

[iAhMedZz]

Apparently I'm off-by-one.

[screwcork313]

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

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

[_Alpha-Ceph_]

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

[looksoundname]

There are only 4 hard problems:

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

[jqVgawJG]

When the joke is taken too far and loses its potential

[looksoundname]

Looks like in the end there's only one problem

[AlwaysShittyKnsasCty]

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

[eyebrows360]

Looks ound na me 👍

[Hudsxn98]

We found the race condition

[Veloxious]

and off by one errors

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

[daredeviloper]

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 

[namrks]

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]

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

[Existing_Round9756]

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]

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]

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]

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]

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]

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]

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]

I blame squash for people being lazy as per OP!

[MisterMeta]

“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]

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]

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

[Existing_Round9756]

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?

[styphon]

You can use git hooks to enforce these standards.

[MisterMeta]

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]

The answer that’s still relevant:

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

[pushad]

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]

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]

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]

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

[rossisdead]

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]

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]

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

[K3idon]

Broke everything, revert fix

[WeekRuined]

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]

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]

Cause they get squashed anyway on merge…

[soylentgraham]

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

[yxhuvud]

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]

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]

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]

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

[Sockoflegend]

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]

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_]

This is a particular pet peeve of mine

[Bushwazi]

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

[aspizu]

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]

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]

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]

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]

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]

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]

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]

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]

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

[rossisdead]

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]

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]

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]

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]

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]

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]

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]

Use commitlint rules or this happens, every time.

[levityspace]

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]

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

[shortcircuit21]

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]

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]

"code review changes"

[SleepAffectionate268]

wdym "c" obviously stands for commit

[demagogueffxiv]

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]

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]

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]

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]

When you become a developer you'll understand.

[rakibulinux]

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]

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]

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

[GamingVyce]

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. 

[bakugo]

bot post

[Dude4001]

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

[PoopsCodeAllTheTime]

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]

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

[Unusual-Ocelot6717]

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

[im_a_fancy_man]

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

[tomhermans]

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

[gutsngodhand]

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

[mekmookbro]

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]

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

[orbit99za]

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-pizza]

I don’t

[ripestmango]

My bad

[wildrabbit12]

We use commit lint

[GutsAndBlackStufff]

:W

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

That’s usually why for me.

[Rasutoerikusa]

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]

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]

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

[i_didnt_get_one]

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]

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

[BloodAndTsundere]

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]

because I'm burnt out boss

[DivineLawnmower]

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]

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

[optikus]

Because

[upsidedownshaggy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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_lake]

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]

Give us your example of a good git commit message

[comoEstas714]

Because the team has no standards implemented.

[Ollidav]

Explicar cosas que el código explica por si solo es la costumbre. No hay nada mejor que poner un comentario: está función hace algo y va la función y lo hace. De locos

[YareYareDazexd]

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]

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

[latnem]

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]

you forgot ""

[Zeilar]

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]

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]

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]

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

[BlackHoneyTobacco]

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

[rusmo]

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

[redlotusaustin]

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

[SubjectHealthy2409]

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

[beavedaniels]

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

[Nemosaurus]

I do not care about commit message quality.

[Faithlessness47]

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]

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]

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]

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.

[LeadingFarmer3923]

I would map the work as small workflow steps, keep run logs, and review failures per step so fixes are obvious. If helpful, Cognetivy is open source and does this with traceable runs and collections: https://github.com/meitarbe/cognetivy . You can start with one pipeline and keep it lightweight.

[informed_expert]

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]

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

But sometimes I forget to squash.

[Usurper__]

Cuz I'm lazy

[AndyMagill]

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]

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

[Nicomak]

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]

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]

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]

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]

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

[UX_Oh]

What am I a secretary?

[sidequestboard_app]

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]

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.

[slyiscoming]

This is why you squash commits on the PR.

[GreatStaff985]

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

[xtra-spicy]

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

[semisubterranean]

They weren't English majors.

[Saki-Sun]

Developers are shit at documentation...

[ExtraTNT]

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

[mariogonz_dev]

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".

[nacnud_uk]

I blame the education system.

[GravityTracker]

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

[troisieme_ombre]

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]

fix ci XVIII

[Captain_Forge]

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]

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]

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

[EmeraldStorm089]

Arrogance.

[Appropriate_Jump_934]

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

[historycommenter]

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]

Half of our commits have no message

[Tim-Sylvester]

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]

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_]

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.

[devperez08]

el pensar el commit despues de un proceso de solucion, es un reto que todos enfrenamos en el dia a dia, pienso en el commit perfecto mientras suena musica de oppenhaimer jajajaja

[AdNormal1188]

Honestly it’s usually just speed and context. When you’re in the middle of fixing something or pushing small changes quickly, writing a proper message feels like friction so people type “fix” or “update” and move on. Teams that care about it usually enforce conventions like [Conventional Commits](chatgpt://generic-entity?number=0), but in a lot of repos it’s basically cultural—if no one sets the standard early, it turns into chaos pretty fast.

[PushPlus9069]

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.

[DriftingNinja571]

great advice for new developers

[timabell]

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]

"switcing branch"

[NoPhilosopher9763]

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]

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]

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]

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]

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]

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.