We need to talk about our git workflow because the way we are doing it right now it’s not working.
This is what we are doing:
- Open new branch for each fix/feature.
- Push commits. None of them are tagged with
fix or feat.
- Open PR and wait for review.
- Merge once approved. In the merge message, include
fix or feat.
I really like that approach but it doesn’t work because it looks like the conventional changelog we are using (from lerna?) ignores merge commit messages, so our changelogs don’t reflect the fixes or features added.
My first suggestion to try is to squash our merges. I think then the merge commit message won’t be ignored:
It has some advantages. For example, the external contributors don’t need to write conventional commits in their PRs.
And it has some disadvantages. I think we will lose the individual commits of each fix/features branch.
Opinions? Any other suggestion?
I’ve done a squash but it’s a shame because the original commits will be lost once you delete the PR branch:
For really long and complex PRs you lose the ability to see the progress and individual file changes.
Uh, they are lost in git but they are available in GitHub 
Just to confirm, I have released a new version and yes, the squash worked and the merge didn’t:
I think that even if the initial commits are lost, is not that big of a deal. We are interested in the final result, while the commits in that branch might be completely random depending on when we need to push.
One great thing about this is that other people don’t need to follow the conventional standard in their PRs and we, as mergers, get the opportunity to add the info we want in the changelog.
If we follow this approach, should we remove commitlint from husky? What do you think? It doesn’t make much sense that all our commits are chores…
This is the point where I’d love that someone from the community with more experience in this would chime in to give us some advice 
There’s a problem: breaking changes. They are in the commit body and not in the title.
So for breaking changes we need to do a commit and then a merge, instead of a squash. Kind of a pity 
When you do that, the recommendation is the merge instead of the squash:
