Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conventional Commits

conventionalcommits.org

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Conventional Commits

#11

Post by ljm »

OpossumMinister wrote: post #7

After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…

This was so bad at one point that I changed my git aliases to include '--no-verify'.

I like to push all my commits up so I can pull them back on a different machine or get early feedback. I'll typically rebase at the end with a proper commit message and explanation for each logical change.

Re: Conventional Commits

#12

Post by oppodeldoc »

thephyber wrote: post #3

The most interesting things about Conventional Commits are that they can be deterministically digested by a process to decide how to bump a SemVer and similarly to create a formatted CHANGELOG file.

Yeah, https://github.com/conventional-changelog/standard-version is a really great tool for this, we use it and the versioning is relatively seamless for releases.

Re: Conventional Commits

#13

Post by jasonpeacock »

ArchOversight wrote: post #10
wffurr wrote: post #8

Earlier quoted context omitted.

Squash merge and commit linter only on master seems like the way to go here. Then you can do whatever you want in your feature branch, and then when the feature is ready, create the squashed commit with the proper commit formatting.

squash merges to master are terrible for those that want to go looking why a certain change was introduced. Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py. Commit messages should explain why the change was made to the code. The amount of…

You're describing the wrong use of squash merges, and I agree they suck.

The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change.

And the commit description will describe what's going on.

The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back into mainline and then starting on the next step.

Re: Conventional Commits

#14

Post by BenjaminCoe »

Hey,

I'm the original co-author of the "Conventional Commits" spec. Although, I should give credit where credit is due, and say that it evolves directly from Angular commit conventions.

I started adopting these conventions with the goal of automating releases, both on my open-source and on the services I was working on at npm (I've since brought the practice to my team at Google).

I very much did not want to introduce road blocks to folks committing to their own branches -- which is what the "rewrite the message when you squash" advice grows from.

Here's a post I wrote on how my team uses Conventional Commits in our release process:

https://dev.to/bcoe/how-my-team-releases-libraries-23el

Re: Conventional Commits

#15

Post by w0utert »

jasonpeacock wrote: post #13
ArchOversight wrote: post #10

Earlier quoted context omitted.

squash merges to master are terrible for those that want to go looking why a certain change was introduced. Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py. Commit messages should explain why the change was made to the code. The amount of…

You're describing the wrong use of squash merges, and I agree they suck. The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change. And the commit description will describe what's going on. The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back…

If you do this for short-lived feature branches only, why do you even need to squash merge for this? What I typically do for such things is to have a WIP commit that I amend and force push while working on the feature, then when everything is ready to merge I reset —-soft and make separate commits for each part of the work that can be compiled and tested indivually, rebase onto master and then fast-forward merge.

Re: Conventional Commits

#16

Post by ncphillips »

OpossumMinister wrote: post #7

After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…

There's an easy workaround: use the "chore" tag.

    chore: injecting logger
I've been working on a project for months that uses this exact setup (commits are rejected if they are not formatted correctly) and the problem you describe just isn't that big of a deal. The benefits to the projects far outweigh the mild inconvenience.

Re: Conventional Commits

#17

Post by runarberg »

thephyber wrote: post #3

The most interesting things about Conventional Commits are that they can be deterministically digested by a process to decide how to bump a SemVer and similarly to create a formatted CHANGELOG file.

I really wished we had type systems good enough, and tools smart enough to figure the semver bump by it self. Ideally humans should not come near semver bumping, not even through the commit messages.

Re: Conventional Commits

#18

Post by [deleted] »

OpossumMinister wrote: post #7

After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…

[deleted]

Re: Conventional Commits

#19

Post by ArchOversight »

jasonpeacock wrote: post #13
ArchOversight wrote: post #10

Earlier quoted context omitted.

squash merges to master are terrible for those that want to go looking why a certain change was introduced. Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py. Commit messages should explain why the change was made to the code. The amount of…

You're describing the wrong use of squash merges, and I agree they suck. The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change. And the commit description will describe what's going on. The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back…

Even for a short lived feature branch that lasts maybe a day or so there may be a bug you find during testing that you quickly fix, or a change you make in existing code to help support the new feature or something you know is coming down the pipeline, and that information is now lost.

Re: Conventional Commits

#20

Post by yawaramin »

ArchOversight wrote: post #19
jasonpeacock wrote: post #13

Earlier quoted context omitted.

You're describing the wrong use of squash merges, and I agree they suck. The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change. And the commit description will describe what's going on. The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back…

Even for a short lived feature branch that lasts maybe a day or so there may be a bug you find during testing that you quickly fix, or a change you make in existing code to help support the new feature or something you know is coming down the pipeline, and that information is now lost.

You can say that about any commit in the repo, no matter how granular the commits are.
Post reply on HN