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

61–70 of 185 posts

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

#61

Post by scoot »

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…

Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?

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

#62

Post by tjr225 »

scoot wrote: post #61
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…

Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?

Are you being serious?

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

#63

Post by gunfighthacksaw »

scoot wrote: post #61
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…

Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?

I don’t particularly enjoy cleaning my house but I love the aftermath.

Same with bumping versions on dependencies. If I didn’t have to do it I’d love to just get the new features in a non-breaking way. But I can’t, so I do, and it’s a chore.

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

#64

Post by teeray »

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

If you don’t supply `-m`, `git` will pop open your `$EDITOR` with the new commit message. You can use whatever tools you like to wrangle text in there. I use vim, so it’s just a quick `gq` to format everything.

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

#66

Post by Izkata »

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

> 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch

Please don't do this. It erases history that's really useful for tracking down the cause of bugs.

There's plenty of ways to use git log to filter commits if a pretty history is your goal.

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

#67

Post by woojoo666 »

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

I agree with this. Oftentimes I am experimenting around (obviously on a separate branch) and use commits as checkpoints. Not every commit is a perfectly polished state. Using separate branches and then squashing when it is ready, gives me the freedom to experiment without constraint, and then clean things up when it is ready

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

#68

Post by sodality2 »

scoot wrote: post #61
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…

Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?

It doesn't literally mean chore. It means a code change that you do regularly but is not major, and usually doesn't require much work (update dependencies being a good example).

> Chore: A routine or minor duty or task

Rather than

> Chore: An unpleasant or burdensome task

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

#69

Post by teeray »

carlosdp wrote: post #2

I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…

I abhor “Squash and Merge”, because I do take time to make good commits. They each pass tests, they have messages, and I rebase fixup commits away. For me, a merge commit is semantically meaningful (it even gives me a place to put who reviewed it in the merge commit message).

This probably seems like a whole lot of work for no benefit. However, I can’t tell you he number of times I’ve been on crappy plane wifi, hit `git blame` on some line and been able to comprehend my state of mind making a change years in the past.

Git history is a form of communication.

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

#70

Post by ilammy »

emacs28 wrote: post #58
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've been using github-changelog-generator [1] for (you guessed it) automatic changelog generation, which adds bug fixes/features to the changelog based on issues and PRs, but sematic-release looks like it might be even more useful. [1] https://github.com/github-changelog-generator/github-changel...

These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communicating changes by replacing it with "interesting" work of massaging git history, inventing microformats, etc. Why bother with separate changelogs at all then when you can see changes in `git log`. Just write good commit messages! /s
Post reply on HN