Repository conventions: develop branch + WIP pull requests

[lauritzthamsen]

yesterday @TobiasHerb and I discussed how integrate changes more often and how to make ongoing work more visible for all on github.

here two ideas:

first idea: use a develop branch and roughly follow the gitflow workflow. this way, we have a dedicated branch to exchange changes that should eventually land in master but haven't been tested on the cluster before, while the master still only points to versions that have been tested on the cluster.

second idea: use WIP pull requests to describe ongoing work in feature branches. this allows to discuss ongoing work (on the level of code and commits) and makes ongoing efforts more visible.

i created a wiki page for this proposal: Repository Conventions

[lauritzthamsen]

i removed the open question with a note on rebasing instead of merging after discussing it offline.

[lauritzthamsen]

anyone any objections? or do we want to close this issue (and follow the proposed conventions)?

[aalexandrov]

Please leave this issue open for now. I would like to revisit the "rebasing instead of merging" question after 2-3 months with merge-based PRs.

I was not able to participate in the offline discussion and am not convinced by the pros of the always merge strategy. In particular, I have my reservations that:

• The commit graph will look like spaghetti (see the image below).
• The one-sentence commit history will be too detailed to get an overview of what features were recently implemented with git log -n{X} --pretty=oneline.

Let's just try it out and revisit whether a detailed commit history and an always merge policy for PRs actually helps or not.

PS. A good article on the pros and cons of "rabasing vs merging" can be found here.