Semantic Release: Squash commits make for bad CHANGELOGS

[cjthompson]

Problem

semantic release uses the first line of the commit message to determine which update type AND WHICH PACKAGE the change belongs to.

With squash commits, the CHANGELOGs for each updated package are wrong because there's only one big commit.

##Example:

fix(asset-service): fix cosmos precision values

feat(market-service): add cosmos data service

Only asset-service changelog will get an entry. Both packages will get a PATCH bump due to the fix reference even though market service should be a MINOR.

Question

Should we go to MERGE commits and force commit message linting for every commit? This would require people to rework their commits so every commit has a valid message. This might mean doing local squashes or rewriting commits before submitting the PR.

[mrnerdhair]

I already do rebasing and history rewrites religiously because otherwise there's no way for anyone to understand my PRs. I'm in favor of going to merge commits because it makes the product better while only increasing the workload of others.

/jk

Seriously, though, I do see value in doing a rebase step that makes each commit single-purpose, which is why try to I make a point of it, and I'd love to see the practice expand. It makes life easier on reviewers, especially now that GH has built-in file browsing and single-commit selection in the review tab, and makes backtracking root causes of issues much easier. (In the worst case, the itemized source commits of squash-merges can get garbage collected eventually once the PR's branch is deleted, which really sucks.)

[gomesalexandre]

Agreed with @mrnerdhair on MERGE commits and enforcing commits lint - I'm not going to paraphrase this since I agree on every single point.

It's fine to YOLO your commits when you're working locally or are in the context of a draft, but the second you open the review, you should have a clean commit history.
Knowing that commits are going to get squashed currently also brings less incentive for contributors to have a clean, single-purpose-commits history and as a wise man @0xdef1cafe once said this isn't git 101, we should strive for quality commits that make reviewers life easier.

[mrnerdhair]

Actually, I'm not super hot on merge commits either -- I've experienced too many gotchas where the individual commits work but the automerge breaks something and it gets hidden in the merge commit. I'd really prefer to only permit fast-forward merges on protected branches (unless a merge is really necessary, as in e.g. merging a hotfixed main back to develop), where the outcome of mashing the big green button is literally just resetting the target branch to point to the same exact commit as the source branch. Alas, while that's IMO the most natural way to manage a git repo, GitHub doesn't really provide support for it in their UI. (Their rebase merges, IIRC, will rewrite history and change commit hashes even if the PR branch is fully up-to-date already.)