Future of PR merges

[silvanheller]

Currently, we merge PRs "as-is", with a full commit history. While this is not bad per se, it clutters the commit history with commits which can anyway not be reverted to (since ideally, a PR only has a single "feature").

I'd avocate for the following:

• all PRs targeting dev are squashed into one commit (potentially also rebased), since features should probably anyway be developed on separate branches (except for branches which are already cleaned up)
• PRs from dev to master are not squashed - here, the commits actually represent real features
• all PRs to master except those from dev are also squashed.

As an example, see https://github.com/polypheny/Polypheny-DB/commits/master

Thoughts? @sauterl @lucaro @Spiess

[lucaro]

Sounds reasonable to me. I don't quite understand the 3rd point though, what use cases do you imagine where we would have PRs which go directly to master, not going via dev? I'd imagine this only being some minor fixes, that can be done in one commit anyway?

[silvanheller]

Sounds reasonable to me. I don't quite understand the 3rd point though, what use cases do you imagine where we would have PRs which go directly to master, not going via dev? I'd imagine this only being some minor fixes, that can be done in one commit anyway?

#241 for example

[lucaro]

fair enough, that was supposed to be one commit anyway...

[sauterl]

As @lucaro pointed out, it was supposed to be a single commit. Since I already pushed to the remote branch, I felt it wouldn't be a good idea to partially rewrite the history, when the fix would be to simply squash to a single commit upon merge.

[Spiess]

I think this is a very good idea, especially because it will hopefully reinforce the practice of keeping branches focused on the feature they are implementing.

[sauterl]

Thanks, @silvanheller for the suggestion. I personally thnk any step towards a formalised process is beneficial for this project.

One minor note though, since there sometimes there are Bachelor's / Master's Theses involved, I suggest to explicitely continue the notation you used recently while merging:

 * Short feature description by @user (#ticket)