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

91–100 of 185 posts

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

#91

Post by darylteo »

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 contributed projects perhaps where the benefit of conventional style is to be able to easily create changelogs of large number of commits.

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

#92

Post by [deleted] »

scoot wrote: post #76
sodality2 wrote: post #68

Earlier quoted context omitted.

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

> It means a code change that you do regularly but is not major So "update". Attaching emotionally charged words like "chore" does nobody any favors, and in fact has negative consequences.

[deleted]

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

#93

Post by rafaele »

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 commit messages in the indicative tense, part of me notices, but I move on because I can still understand the message if it adheres to the other guidelines.

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

#94

Post by logbiscuitswave »

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…

It may be heretical but I tend to agree with this. Also at my workplace we tend to be standardized around PRs doing squash merges so there’s not really much point in having detailed interim commit messages anyway. As long as the PR has good information (and of course is linked to useful work items with good information) that’s usually good enough for me.

(Of course more often than not people have empty/useless linked work items, and PRs with useless titles and descriptions but that’s a whole different kind of problem.)

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

#95

Post by adastra22 »

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.

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

#96

Post by brunellus »

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…

The individual commits aren’t interesting until you need them. They should be organized such that they remove the desire to squash them together.

Having a well written commit history is in the spirit of the tool and is the more professional approach.

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

#97

Post by emacs28 »

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 totally agree with this, I'm not a fan of the written-in-stone nature of commit messages. Just like code, it's nice if log history is editable too in case your forgot something, or if you want the message to mention future changes that back reference it.

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

#98

Post by tln »

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 with you!

The PR commit can have sooo much good information, that can be used by so many teams. Loom videos for a quick demo of the feature. A concise description of the impact on customers, support teams. Deployment and feature rollout considerations.

I do try to make the individual commits somewhat presentable within the PR... a few extra minutes polishing the subjects lines. But nowhere near what this article, which seems to be suited for non-PR workflows such as mailing lists+patches, or workflows where every PR is squashed?

There's even a pitfall in putting too much "why" in the commit messages -- some programmers will be tempted to keep it out of the code, ie never comment their code.

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

#99

Post by synicalx »

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?

Most people don't have the luxury of picking and choosing exactly what they work on. I don't WANT to work on keeping some legacy tooling from falling apart, and I would consider maintaining it a chore. That doesn't mean that it can just be abandoned though, so my boss will tell me (or someone else) to go work on it when needed and that's a perfectly normal and acceptable thing to happen in a workplace.

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

#100

Post by owalt »

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…

None of this is really worth obsessing over I think, but one point in favor of imperative is it tends to also be the tersest phrasing, which is convenient if you're also aiming for 50 characters max.
Post reply on HN