Git merge branching good practices
The leading principal is that master branch (trunk in SVN) has all the commits and the branches of the specific versions are a subset of commits. All commits on branches will eventually end up on master.
Master will contain the main developments, holding possible unstable features. Experimental (very very unstable) features should be placed on another branch.
You start with the master. Then, you start a release version branch: svbranch. In the beginning the master and svbranch are the same.
Then you start committing and pushing to svbranch. At the same time, there are other commits pushed to master. These commits are not for svbranch, but for a future version (maybe because they are unstable).
These commits pushed to master after creating svbranch will never be on svbranch.
At some point, you can merge svbranch to master, so the features pushed to this branch are also available on master. You can do it as often as you want.
You should never merge from master to svbranch, unless you are pretty sure no unstable features will be drag fro master to svbranch. (Which, if this guideline is correctly adopted, will not happen often).
When adding a new feature you should branch from the master or the specific version you are developing for. If you want to include your feature in an existing specific version, you have to clone that specific version.
Otherwise, if you merge your feature on master and then want to move that feature to a specific version, you will drag all the commits on master to the specific version.
Picture it as a flux. Once you push something to a branch, it is dissolved in that branch and you cannot remove it anymore.
You don't. If you want to cherry pick it's because someone (probably you) messed things up.
What does a normal pull request ask you to merge? You have to see only the commits you have done. If there are commits on your side that you don't want to merge, just create a new clean branch based on the version you want to merge to, cherry pick there, check everything is ok and then pull request.
Never cherry pick directly to master or a release version branch.
Just follow the guidelines described before.
Work on the release version branch and then, when the specific version has this commit pushed, ask for merging this release version branch to master.
This way, commits will go first to the release version branch and then directly to master.
What about commits on the specific version that should not be on branch (like changing the version number)?
Just do it first on the specific version, commit, push, merge with master and change it again on master.
A bit dirty, but better than breaking the flux.
Try here: http://nvie.com/posts/a-successful-git-branching-model/