Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to write a Git commit message (2014)

cbea.ms

Post reply on HN
Print view View original

101–110 of 185 posts

Re: How to write a Git commit message (2014)

#101

Post by synicalx »

rafaele wrote: post #93

What do people think of this line? > Use the imperative mood in the subject line The only rationales I've seen for using imperative ("fix bug") over the indicative ("fixed bug") are that it's what git does by default anyways. Is it really that big of a deal to use the indicative sometimes and imperative other times? For what it's worth, I always write commit messages in the imperative, out of habit. When others write…

So long as the meaning is clear, it really doesn't matter IMO. Just write it so that when viewed in isolation the meaning of the message is clear and matches the changes held within the commit.

Anyone who gets up in arms over "fixed" vs "fix" needs to get a life.

Re: How to write a Git commit message (2014)

#102

Post by ridiculous_fish »

themanmaran wrote: post #9

For those who write multi paragraph commit bodys, is there a tool you use to format them? Example commit on the React repo [1]. It just seems like a lot to type in the command line. [1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...

I write it as normal prose and then pipe through `fold -w 76 -s` to line break. TextMate makes this easy with its "Filter Through Command" menu item.

Re: How to write a Git commit message (2014)

#103

Post by tjr225 »

scoot wrote: post #65
tjr225 wrote: post #62

Earlier quoted context omitted.

Are you being serious?

Yes. Are you?

Yup, you should re-evaluate. There are a jillion reasons to do things that are chores. The word chore should not be implicitly perceived as a negative thing.

Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself.

I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.

Re: How to write a Git commit message (2014)

#104

Post by rectang »

lamontcg wrote: post #90

I'm a heretic who prefers information in the PR. That's where the long-form back and forth arguments happen over the edge conditions. Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity. Yeah that means all the important information is in GH but if you migrate to GitL…

I'm an agnostic who keeps my distance from self-proclaimed heretics inhabiting the modern-day Church of Github (which formed as an offshoot of the Cult of Git, which itself emerged after launching a savage religious war with the iconoclastic Sect of Subversion), who prefers to have both a logical, reviewable commit history AND informational pull requests.

Smashing commit history via squash makes debugging harder. Provided you have the interactive rebase chops to pull off crafting a decent granular history, you'll reap significant dividends down the road if you keep that history intact. Because it's right there for you to use with `git blame`, etc.

And then why not have proper discussions in the pull request with reviewers? Sometimes important stuff comes up in review. Sometimes you might close the PR and start anew. Sometimes the PR gets incredibly lengthy. Maybe the result is a commit history which condenses some abominably lengthy PR.

There's no need to choose between them. You can have both!

Re: How to write a Git commit message (2014)

#105

Post by lamontcg »

adastra22 wrote: post #95
lamontcg wrote: post #90

I'm a heretic who prefers information in the PR. That's where the long-form back and forth arguments happen over the edge conditions. Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity. Yeah that means all the important information is in GH but if you migrate to GitL…

Write a commit script that pulls in the PR text into the merge commit.

> Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity.

Re: How to write a Git commit message (2014)

#107

Post by emacs28 »

est31 wrote: post #89
emacs28 wrote: post #79

Earlier quoted context omitted.

Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.

Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are impor…

These are good points. Just to clarify, I can't speak for semantic release, but the github-changelog-generator I'm talking about will only add PRs (and issues if you want) to the changelog, not commits (so no non-standard commit message format needed). So you can put anything worth mentioning in a changelog into a PR, and it distinguishes between bug fix vs feature based on the tags added to the PR.

Re: How to write a Git commit message (2014)

#108

Post by _ZeD_ »

_virtu wrote: post #28
bern4444 wrote: post #10

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore…

I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versio…

Oh, gosh.. no

The commit messages are meant to be read by humans

Re: How to write a Git commit message (2014)

#109

Post by [deleted] »

lamontcg wrote: post #90

I'm a heretic who prefers information in the PR. That's where the long-form back and forth arguments happen over the edge conditions. Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity. Yeah that means all the important information is in GH but if you migrate to GitL…

[deleted]

Re: How to write a Git commit message (2014)

#110

Post by bern4444 »

_virtu wrote: post #28
bern4444 wrote: post #10

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore…

I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versio…

I did this at one company too using commitizen to use a cli wizard for helping ppl get started (exposed it through an npm script, npm commit i think) but also setting up a commit linter that would run as a post commit hook and reject the commit if it was incorrectly formatted.

It helps get everyone using it familiar quickly despite being annoying as you get used to it.

Post reply on HN