Enforcing one rebase/merge strategy

[aiven-sal]

My personal preference, when it comes to git, is "semi-linear history".
Maybe it isn't the most common way of doing things, but I think it is the best one when you need to look at the history, trying to understand how certain changes landed in main.

Quoting this article:

This strategy is the most exotic – it’s a mix of rebase and a merge. First, the commits in the pull request are rebased on top of the master branch. Then those rebased pull requests are merged into master branch. It emulates running git rebase master on the pull request branch, followed by git merge pr --no-ff on the master branch.
Some people think of this as the best of both worlds: individual commits are retained, so that you can see how the work evolved, but instead of just being rebased, a “merge bubble” is shown so that you can immediately see the work in each individual pull request.

This approach is exotic enough that GH isn't able to enforce it out of the box, but there is an action for it: https://github.com/marketplace/actions/forbid-merge-commits

This is really a matter of personal taste.
What do you think about this? Do you like the idea? Shall we enable this action?
Do you want to propose a different model?

@mkmkme @ahmedsobeh

[mkmkme]

This is actually also my personal favourite that I'm trying to keep in all my projects. I do think it's best of both words. So definitely 👍 from me

[ahmedsobeh]

I've usually used "squash an merge", so each commit would represent a PR with its description as the commit title. But this also works for me and serves the same purpose, I guess the only downside is more work "rebasing" for potential contributors, but that should be fine I think.

TL;DR, 👍 from me

[aiven-sal]

Thanks both!