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

111–120 of 185 posts

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

#111

Post by bern4444 »

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?

The example using chore is a part of the conventional commit types to mean this commit is less significant. I often use it for things like

chore: resolve a merge conflict

chore: fix code formatting

chore: update dependency type definitions library

Each of these things is nice to have tracked as their own commit so they don’t show up in other more impactful or isolated commits. They don’t add a lot to the code but are rather little house keeping actions that help keep a codebase clean and up to date.

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

#113

Post by fn1 »

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…

Interesting, after years of software-development I arrived at almost the same pattern:

* [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way.

* [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature

* [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug.

Sometimes I also use:

* [build] -> for build-improvements

* [performance] -> for performance-improvements

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

#114

Post by twhitmore »

Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read.

For example:

----------------

improve Buffer Cache Management & logging

- change 'tryDrop()' to skip immediately, if lock unavailable

- move BufferCache logging to a separate logger

- attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers

--------------------------------

Having worked in many codebases & internal docs, I've found narrative significantly less efficient to read & write.

In commit messages, far too many developers skip almost any detail as to what they're changing & why -- the slowness of narrative formats may substantially contribute to this. In docs (Wiki etc), narrative encourages developers to ramble about minor technical details while omitting all high-level context.

Headline + bullet-points bypass a lot of struggles with narrative by allowing a simple headline and then, well, cutting to the point.

This also illustrates a informed personal preference -- studies find lowercase English words faster to scan/ comprehend.

See: http://literatejava.com/git/how-to-write-a-good-git-commit-m...

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

#115

Post by kgeist »

We also have a rule to prepend every commit message with its issue number in our issue tracker (we don't use GitHub). That way in Git Blame/Log you can always quickly find where the change came from and why - the issue tracker usually has more detailed information.

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

#116

Post by _kblcuk_ »

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 used to do that as well. The problem here is that PR belongs to a particular service provider (GitHub, GitLab and whatnot), and thus can be easily lost if you move providers. Or even if you simply move commits to a new repository (for instance you need to clean out some sensitive information from git history). In that sense having as much context in commit messages themselves saves the day.

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

#117

Post by alexeiz »

My opinion about Git commit messages has always been the same: if you can't describe it in English, you don't know what you're committing. If your commit message is too long and messy, you're committing unrelated things that should be split into multiple commits. The commit message is a direct indicator of the quality of your commit.

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

#119

Post by beermonster »

Is there a reason why GitHub don’t make it easy in 2022 to write nice commit messages? Larger boxes, visual cues for character length, non default commit messages such as ‘Updated doc blah’ which are useless.

Lots at our place solely use the GitHub UI to edit Markdown files mainly and their messages are typically the least useful for that reason.

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

#120

Post by travbrack »

slaymaker1907 wrote: post #34
stormbrew wrote: post #22

Earlier quoted context omitted.

> Having whitespace-altering "Dummy commit to trigger CI, ugh!" commits in a git history isn't good but it still clutters the `git log` with stock squash+merge GitHub use. The frustrating thing about this is that this "omg minor commits on a merged branch clutter up the log!" is entirely a UI problem created by github's naive view of history where it shows things in a bafflingly obtuse linear order instead of letting…

It would also help if people were better about keeping a clean commit history for PRs. Ideally, a new commit should only get pushed to a branch per change relevant for reviewers. If the CI is causing the error, people should work on a temporary branch and resolve it there first before cherry picking things over into the PR branch (after rebasing the intermediate commits on the temp branch). Rebasing is a really nice…

Love the sub-branch idea. I'm going to use that.
Post reply on HN