Conventional Commits • Hacker News Board

Re: Conventional Commits

#21

Post by yawaramin » Thu, Aug 20, 2020, 2:44 AM UTC

w0utert wrote: post #15

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…

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.

I think you just answered your own question. Compared to your workflow, the squash-merge workflow allows:

- Commit and push naturally as you work

- Reviewers to look at individual commits separately after having already reviewed previous commits

- Squash-and-merge with one click (usually, e.g. GitHub) instead of messing around with git resets and branch history.

Re: Conventional Commits

#22

Post by yawaramin » Thu, Aug 20, 2020, 2:46 AM UTC

runarberg wrote: post #17

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.

Elm does have a type-directed version bump tool. Is that what you were thinking of?

Re: Conventional Commits

#23

Post by yawaramin » Thu, Aug 20, 2020, 2:50 AM UTC

My take on this is that, all else being equal, it seems the major selling point of Conventional Commits is that their commit summaries can be used to calculate the next version bump. But IMHO, instead of asking everyone to annotate every single commit message with a marker just so a separate tool can process it (possibly to get it wrong), it's better to just update the version directly when making changes. This way the version bump is deliberately and carefully thought out, and doesn't need to pollute all commit messages in the process.

Re: Conventional Commits

#24

Post by lefrenchy » Thu, Aug 20, 2020, 5:12 AM UTC

ncphillips wrote: post #16

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.

I totally agree. I think the complaints are valid, but to be honest it seems petty. There are ways around it like you suggested. Having stuff like this really helps to solve process problems like not keeping a changelog up to date or incorrect version bumps, that can be a pain to manage across engineers. I think it’s important to consider that it helps the team as a whole.

Re: Conventional Commits

#25

Post by jmcqk6 » Thu, Aug 20, 2020, 1:36 PM UTC

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.

Or you could make consideration for tracking that change in source code a priority when making those changes and code appropriately.

The problem you describe is a problem because people are not prioritizing or valuing the commit history as a resource. If you fix that, then people will think about these things differently.

Squash and merge is not the only way to get things into master. You can rebase and squash commits as needed on your branch and then bring multiple commits from your branch onto master. That takes more advanced usage of git, but learning that makes sense once you start really valuing the history.