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

141–150 of 185 posts

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

#141

Post by iggldiggl »

stormbrew wrote: post #55
mwt wrote: post #38

Earlier quoted context omitted.

> github's naive view of history where it shows things in a bafflingly obtuse linear This hits home, it pretty much describes how I visualize logs in my head (compared to the visualizations I see that are more 2-D, branching off and merging together, etc.). I have a hard time working with some of the more advanced features because of this, and it'll probably always be an uphill battle to shift my thinking from linear…

The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1]. Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large str…

> The obtuse part about github's linear view isn't that it's linear, it's that it's interleaved by time in ways that form a chaotic view even for a linear one. Like, picking a random large project for an example, take a look at swift's history on github[1].

> Because there's a bunch of PRs that were being operated on in parallel, and some probably that are even kind of old, the view you wind up with is likely a large streak of "PR merged" commits and then all the commits from those PRs jumbled together in an incoherent mess.

Oh yes, I've just run into this problem myself: I had to backport a large set of commits. While they're of course roughly chronological, they're not strictly so, and so the result in Github's UI is a giant mess.

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

#142

Post by kgeist »

selcuka wrote: post #138
kgeist wrote: post #115

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.

We do the same and it works pretty well. The problem with that approach, though, the codebase may live for decades but issue trackers change and old tickets usually don't get migrated to the new system.

>old tickets usually don't get migrated to the new system

Well, our current issue tracker was migrated from Jira and I can still see all the ancient Jira tickets just fine (I mean what's important: the comments).

In any case, something is better than nothing at all.

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

#143

Post by beanaroo »

fn1 wrote: post #113
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 tes…

After working on a number of projects that tried to apply conventional commits properly, I found something like this to be more effective and sustainable.

Specifically, I'm quite fond of https://gitmoji.dev

- Commit messages are shorter, even with ticket IDs.

- Commit log is easy to read

- Less prone to typos (chroe vs chore)

- Easy to enforce with push rules

- Easy to generate changelogs/release notes

- Easy to measure (metrics)

- Helpful IDE integrations

- It's a bit more fun than conventional commits

See https://github.com/tiangolo/fastapi for an example

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

#144

Post by [deleted] »

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…

[deleted]

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

#145

Post by DrBazza »

I'm sure quite a few commenters on here only started writing code in the last 15 years. What's interesting is that git is (more or less) the de facto version control system and has been for that 15 years, and that likely means that what you put in your commit messages will stay around forever (for some definition of forever).

As a greybeard I've gone file-based backups, then SCCS, CVS, SVN, and now git for what seems like forever (git was 2005 according to wikipedia), though probably the late 00s. And migrating from one to the next (yes, quant code from the 90s is still running in 2022, and we have the commit messages to prove it).

Some people commenting above/below above the PR being the source of in depth information. As far as PRs are concerned, it's just another issue tracker, and I've been through the lot, also including various git hosting services). The commits travel with the repository. The PR discussions don't.

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

#146

Post by ulflander »

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…

Why not both?

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

#147

Post by epmatsw »

DrBazza wrote: post #145

I'm sure quite a few commenters on here only started writing code in the last 15 years. What's interesting is that git is (more or less) the de facto version control system and has been for that 15 years, and that likely means that what you put in your commit messages will stay around forever (for some definition of forever). As a greybeard I've gone file-based backups, then SCCS, CVS, SVN, and now git for what seems…

100 times this. I’ve worked at a company with a commit history going back to 1979 (literal paper logs at that point, plus in-file headers), and another company where we lost ~2 years worth of historical context/info to WIP commits because “our internal GitHub instance has that info” turned out to not be true when we migrated to a new instance. Nowadays, the relevant info from our PRs gets copied to git, and I hope in 40 years if someone has a question they can still see that history if needed.

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

#149

Post by planede »

I think the most important thing is that the commit message should capture the high level intent of the change. I write "intent", because the actual effect and "intent" can differ, and commit messages are immutable. It's fine, as long as you recognize that the commit message is there to capture original intent. You often see "Fix bug #1234", but you rarely see "Introduce bug #1234".

The other stuff about using consistent tense, capitalization, punctuation, etc... is important, but secondary.

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

#150

Post by darkerside »

twhitmore wrote: post #114

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

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

Post reply on HN