How to write a Git commit message (2014) • Hacker News Board

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

#181

Post by stevula » Sat, Apr 30, 2022, 4:53 AM UTC

darylteo wrote: post #91

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 prefer issue/card numbers as it makes it easier to visually group and search for common commits of a single task in shortlog. feat/fix/chore have no functional use in shortlog (for me!) and the mixed length moves the start of the actual comment and makes shortlog messy. That information can just as easily be put into the commit message. 2c. This is probably more appropriate for private projects rather than public c…

Conventional commits support a scope which can be an issue ID: `feat(37): add foo` The variable length is still a thing though.

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

#182

Post by darkerside » Sat, Apr 30, 2022, 2:14 PM UTC

twhitmore wrote: post #178

darkerside wrote: post #150

Earlier quoted context omitted.

Just thinking out loud, but wouldn't this be best handled with separate commits for each of these atomic changes, with a merge commit describing the intent ins narrative form? Don't ask me if I practice what I pushed there

Good question. The example message is adapted from a fast-moving innovation stream; it's an example of moving quickly and getting a lot of major work done. In a more mature area, pace of work could often be slower and commits more granular. Until it's necessary to refactor/ reengineer things -- then commits are often larger again. That's been my experience anyway, YMMV.

Fair point. We should act appropriately for our context.

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

#183

Post by imwillofficial » Sun, May 01, 2022, 2:28 AM UTC

scoot wrote: post #172

imwillofficial wrote: post #88

Earlier quoted context omitted.

It sounds like you have attached negativity to a relatively harmless word.

Let's just say that one of us is speaking English, and the other thinks that they are.

Let’s just say your understanding of the nuance of English is lacking, and you need to upgrade your knowledge.

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

#184

Post by yencabulator » Mon, May 02, 2022, 6:08 PM UTC

bern4444 wrote: post #111

scoot wrote: post #61

Earlier quoted context omitted.

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…

> chore: resolve a merge conflict

This should never be a standalone commit! A merge conflict is solved by the merge commit, and if you were to override the automatic commit message, this seems like a very information-poor text to replace it with.

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

#185

Post by darylteo » Wed, May 04, 2022, 11:13 PM UTC

ulflander wrote: post #146

darylteo wrote: post #91

Earlier quoted context omitted.

I prefer issue/card numbers as it makes it easier to visually group and search for common commits of a single task in shortlog. feat/fix/chore have no functional use in shortlog (for me!) and the mixed length moves the start of the actual comment and makes shortlog messy. That information can just as easily be put into the commit message. 2c. This is probably more appropriate for private projects rather than public c…

Why not both?

Your commit topic shrinks to only 40-45 characters if you try to do both (card numbers get quite large too if you're in a jira context, with their issue prefixes PROD-001 is 8 characters already) so you pick and choose.

The other thing is that in an internal context, what does knowing whether it's a feature or a bugfix do for you? If it's such a big issue, then it'd be integrated into the issue prefix

BUG-001

FEA-002 Now you have a nice short log that aligns nicely, and you can figure out mostly where your merge points were anyway, so no need for merge commits, rebase works mostly fine.

- BUG-001 fix for this thing

- FEA-005 initial commit

- FEA-005 unit tests

- FEA-005 implement this thing

- FEA-005 implement that thing

- FEA-005 fixes for code review

- BUG-002 fix for another thing

- BUG-002 revert fix did not work

- BUG-003 fix for that annoying thing

Of course, just my 2c and my limited personal experience.