The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
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?
luisherranz2
I’ve done a squash but it’s a shame because the original commits will be lost once you delete the PR branch:
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.
luisherranz6
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…
luisherranz7
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
