Version Control: Using squash merge when merging PRs to master

In my opinion, when we merge PRs, we should be squashing the commits before merging it. A PR is usually related to one logical change as:

• during the course of development, developers usually keep creating commits after small changes
• whenever a PR is reviewed, new commits are made to address issues pointed in reviewer’s comments

Doing a squash would have the following advantages:

• will keep out git history clean. Viewing the git log will clearly show how features were added/things were fixed.
• will make it easier to check the change done by building a particular feature. Rather than viewing multiple commits git show <commit_id> will show the changes
• will make it easier to revert a change
• cherry picking a change to another branch(say release branch) would be much easier. 😃

It would be great if we could reach a consensus on this and start following the practise.

@misaochan @neslihanturan @nicolas-raoul @psh

[misaochan]

I agree with this, especially after having had to cherry pick through multiple-commit PRs recently. 😉

I think the simplest way to do this is for reviewers to use the web interface and click on the drop-down button then select “squash merge”. Given that it’s so simple, if we do decide to go with this, I’d personally prefer to request reviewers to all start right away for consistency (so that we don’t have some squashed commits along with a whole trail of unsquashed ones).

@nicolas-raoul No, senders don’t need to do anything special. 😃

[nicolas-raoul]

Good idea! It does not require the sender of a pull request to do anything special, right?

How about this:

• Suggest that PR reviewers squash before merging
• Since the PR reviewers are already overbooked, they are free to continue the way they are used to, and switch to doing it whenever they have time to experiment.
• When all PR reviewers are used to squashing (could be in a year, we are not in a hurry), make it a rule.