I've never had to do that, so that explains why I would devalue squashing. Out of curiosity, why squash + cherry pick rather than just merge? Also, are you familiar with git-rerere? It repeats conflict resolutions for rebases; I wonder if it does the same for cherry picking!
We have two development branches at most times, a branch with only critical fixes (next), and a development branch with it all (nextnext).
All work branches from develop, but only a few of those go to develop and turn onto the next release branch. We obviously can't merge development branch, as it's got stuff we don't want, and branches are deleted when they merge to development branch.
The only other way would be two pull requests. One to develop and one to next, but that is not without its problems either.
I've never had to do that, so that explains why I would devalue squashing. Out of curiosity, why squash + cherry pick rather than just merge? Also, are you familiar with
git-rerere? It repeats conflict resolutions for rebases; I wonder if it does the same for cherry picking!We have two development branches at most times, a branch with only critical fixes (next), and a development branch with it all (nextnext).
All work branches from develop, but only a few of those go to develop and turn onto the next release branch. We obviously can't merge development branch, as it's got stuff we don't want, and branches are deleted when they merge to development branch.
The only other way would be two pull requests. One to develop and one to next, but that is not without its problems either.
Interesting - thanks for the insight!