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

81–90 of 185 posts

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

#81

Post by tardismechanic »

_virtu wrote: post #28
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 built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versio…

+1 on conventional commits (big fan)

also, +1 on fully paved road approach!

You might want to check out this GitHub Action to enforce PR title matches the spec: https://github.com/amannn/action-semantic-pull-request

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

#82

Post by irrational »

_virtu wrote: post #28
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 built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versio…

> I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds.

I'm not. Writing code and writing git commit messages take entirely different types of thinking. With code you are having to think logically and problem solve to tell the computer what to do. Git messages are more analogous to writing a term paper (though shorter). You have to think about the what you are trying to communicate, how best to describe what this commit is all about, maybe trying to figure out if this counts as a fix or something else, etc. Writing code is fairly easy for me. Writing git commit messages is extremely difficult for me. I sometimes go days without commiting because I'm dreading having to write a commit message.

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

#83

Post by graup »

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.

> chore. noun. a routine task, especially a household one.

What's emotionally charged about this? It seems neutral to me.

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

#84

Post by goombacloud »

I rather prefer the first paragraph to be a problem statement and the second paragraph explain the change in detail. This gives the rationale upfront as the focus and helps to understand the problem and check whether the problem/goal was fully understood when making this change and whether the change actually covers what it should achieve. Overall, the change was/is just a mean to an end and other variations are possible.

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

#85

Post by u801e »

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 prefer Github's method of "git commit messages don't matter, pull requests do".

By doing that, you lock yourself into relying on Github in order to get the context behind a change rather than looking at the commit messages for a particular branch. That means, you cannot easily get that information just using git on the command line. On the other hand, if you put the context in a series of well formatted commit messages, you can get that context by reading through the commit log, either on the command line, or in Github by clicking on each commit.

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

This leads to very large commits which cannot easily be reverted once any other commits that update the same files are added to the base branch. Also, in this case, the merge commits are essentially redundant, so why have them? There's nothing that prevents one from amending their commit to reference the PR number and eliminate the merge commit entirely.

> It's easier to be more expressive in a pull request, and intermediate changes while working on a PR aren't super interesting to me.

It really comes down to how those changes are presented. For example, if the change is one commit that adds a new method, and a second commit that adds calls to that method, that makes the change easier to review. Also, if a bug is found in the method, you can make a revert commit to remove all the calls to the new method, another commit to demonstrate the bug with one or more tests, another commit to fix the bug and update the tests to reflect that the fix works as expected.

If the commit was just a single PR commit, and another PR was merged, then one would have to craft a commit to undo the changes pertaining to that bug and then make a new commit in another PR to add the updated implementation. This makes it harder to see what the fix was since you essentially remove the entire feature and then commit a new version of that feature.

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

#86

Post by Bolkan »

mwt wrote: post #43
transitivebs wrote: post #18

95% of the commits on my personal open source projects use emoji commit messages. https://github.com/transitive-bullshit/commit-emoji PRs matter a lot more than commit messages, especially if you're squashing + merging / rebasing.

Honest question, do you really expect your history to be meaningful long-term? Or are you simply taking the approach that the commit message is meaningless and a developer instead use GitHub search to find a PR relevant to a change they're investigating. For example, I pulled up one of your projects and the history ( https://github.com/transitive-bullshit/kwote/commits/main ) is less than meaningless, compared to i.e…

What if I want to revert to a previous state / compare current state with a previous state. "starting work on bizon gradiants" is way better than .

Edit: apparantly HN blocks emojis. Love this feature.

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

#88

Post by imwillofficial »

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.

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

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

#89

Post by est31 »

emacs28 wrote: post #79
ilammy wrote: post #70

Earlier quoted context omitted.

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

Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.

Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are important as their own unit but your changelog is maybe only interested in a summary.

Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.

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

#90

Post by lamontcg »

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 GitLab or bitbucket or whatever they've got tools to pull all that info along with you when you migrate.

I don't really care about individuals commits other than to find the gitsha to find the PR that they were merged into in order to find the full context.

Post reply on HN