Branching structure

[WeilerP]

@michalk8 (and FYI @Marius1311), I'm continuing the discussion regarding branching structure from #655 - thought it might be best to have this in a separate discussion rather than buried in a PR.

I think cellrank@dev and cellrank@master "diverged" because cellrank@dev was squash merged into cellrank@master. Let's say cellrank@dev is three commits ahead of cellrank@master. If you then

• squash merge cellrank@dev into cellrank@master, GitHub will say that cellrank@dev is three commits ahead and one commit behind cellrank@master
• merge commit cellrank@dev into cellrank@master, GitHub will say that cellrank@dev is one commit behind cellrank@master (that's the merge commit)

Right now, GitHub says that cellrank@master and cellrank@dev are even. This is the case because you merged (merge commit) cellrank@master into cellrank@dev, right?
When merging cellrank@dev into cellrank@master, we should, IMO, be using a simple merge commit, for features, bug fixes, etc. squash merges. This way, cellrank@master mimics cellrank@dev, i.e. the individual feature commits are still visible in its commit history and you can still run git blame and get reasonable results.
Concerning branch names: I personally use

• feat/X (features, enhancements, etc.) is based off the develop branch and squash merged into it again.
• fix/X (bug fixes) is based off the develop branch and squash merged into it again.
• hotfix/X (hotfixes after which new release is tagged) is based off master and squash merged both in master and develop.
• release/X.X.X (releases) is based off develop and merged (merge commit) both into master and develop (in case something was added to the release after branching off develop. You can

The CI can be configured to add a new tag based on the branch name, i.e. for release/X.X.X the new release/tag X.X.X is added. The same goes for hotfixes.

[WeilerP]

This has been implemented in a slightly different form in #725.