I guess you aren't the guy that has to reverse cherry pick, in order, resolving conflicts as you go, to get your feature onto another branch.
We squash, as it makes cherry picking easier. You still have to resolve conflicts of course, but only from a single commit, not up to 23 conflict resolutions from 23 commits that all need to be cherrypicked in reverse order
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.
Remote developer with 17+ years of experience. Mostly worked with PHP and with a passion for REST APIs and front-end interfaces, UX and DX - consequentially working also with React and Svelte.
Location
Rio de Janeiro, Brazil
Education
Universidade Estácio de Sá / Dalhousie University
Work
Remote full-stack developer @ eHungry; past Toptal freelancer
Even in your service-branch and development-branch scenario, I think you can still do a normal merge to one of them, and then do a 3-way rebase on the other. So you don't have to do cherry-pick.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess you aren't the guy that has to reverse cherry pick, in order, resolving conflicts as you go, to get your feature onto another branch.
We squash, as it makes cherry picking easier. You still have to resolve conflicts of course, but only from a single commit, not up to 23 conflict resolutions from 23 commits that all need to be cherrypicked in reverse order
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!
Rob mentioned
rerere
, but that doesn't help when the conflicting code is a moving target between commits :)Even in your service-branch and development-branch scenario, I think you can still do a normal merge to one of them, and then do a 3-way rebase on the other. So you don't have to do cherry-pick.