I think that's a fair idea.

But the 1 commit only is a bit harsh.

Too much?

That's right. Agreed.

Agreed with Olle, I found 1 commit not convenient.
In terms of reverts: You can always revert the merge commit, isn't it?
p.s.
So we can update CONTRIBUTING.md

btw, what is "liner history"?

Linear history means 'no merge commits'.

Yep correct.

See an example of confusion in #737. We can force people to be updated considering the latest master, but if we don't force "Squash and merge" as the only merging strategy, we might end up with these commits in the history: https://github.com/github-changelog-generator/github-changelog-generator/pull/737/commits

If you squash and merge, these commits will not matter anymore, because the corresponding changes are already in master. This has a few benefits:

1. Enforcing the PR maintainer to take into consideration the latest changes we've in master.
2. Discourages rebasing (changing history), so collaborators on a PR don't have to delete the branch and pull it again, when the history changes.
3. Enforces some "post-processing" on the commits in the PR, so we don't end up with small "service" commits, such as "Big commit for the PR" + "Fix" + "Small fix" + "Linter fix"....

What are the downsides you see?

Cons with "squash any PR": Commits can be seen as invididual storytelling 'sentences', where a PR tells a 'story' in a series of sequential 'sentences'. Perhaps authors want that possibility? (Please note: this is not a blocking comment, I'm just describing a way of working.)

Unrelated: Today I went to the Settings to remove Checks for now-removed CircleCI jobs.

Oh cool!

So, I guess it's up to us to decide. I don't have strong preferences either way. I feel that enforcing a PR to be up to date might let us catch some integration issues before landing the changes in the master branch. I found this way of working is fine for small/medium sized open-source projects.

1. "Squash and merge"

I agree with @olleolleolle it would be nice, to leave the "storytelling" feature.
It's important with complex PR, where you try different approaches and fork branches in the middle of the work to try something new. Otherwise, we just lose all the benefits of single commits.

"Big commit for the PR" + "Fix" + "Small fix" + "Linter fix").

• not helpfull ❌ (makes sense to squash them)

In the case of commits like:

"added new class" + "updated dependencies" + "added integration tests"

• looks good ✅

So my propose is: let's try this and make it a default for us.
But I would like to prefer to let developers decide the way how to represent PR.
(for sure, it's redundant if all the commits messages meaningless like

2. Merge commits + master workflow

It's still painful even now.

@ferrarimarco, so, what is the standard workflow?

I will show my workflow.

Please correct/update mine, and we will add it to Contributions section:

1. git pull master
2. git branch -b feature.
3. Do some work in parallel with master.. (git commit -m "some feature")
4. git pull master + Merge master into the feature (git merge --no-ff master) + resolve merge conflicts it needed
5. Make a PR feature -> master (git merge --no-ff feature)

Any ideas on how to make it better?

The workflow looks ok, but how can you enforce no. 4?

The workflow looks ok, but how can you enforce no. 4?

Good question. Don't know how to automate it yet. At least we can set as a rule in contributors guidelines.

You can enforce it by doing as I suggested :)

1. Force the branch to be up to date <- you want this
2. Avoid merge commits <- so merge commits required by the point above don't clutter the history
3. Enable only squash and merge <- same as above

Alright branch protection is in place. Can this Issue be closed now, as implemented?