Going along with what Alain was saying, this is something that confuses me too about why people like the squash workflow. I get uncomfortable at the idea of throwing away all that context! For example, my most recent PR at work had 541 additions and 26 removals across 23 commits. If I had squashed and ended up breaking something, git bisect would be useless for finding the commit that broke things, and if you're looking through the diff, it's much harder to figure out which logical idea in the commit message was responsible for which changed line.
In the interest of building an understanding about why others work the way they do, what are some "pro-squash" benefits?
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.
your PR is too big
its not really checkable nor approvable - noone can hot approval button and consciously share responsiblilty for merging this to master. So go back drawing board, split it up! Respect your git history amd your coworkers time )
I do it all the time - an idea, or a feature first lands in a prototype branch (even TDDed one!) and the I split it to smaller branches that are easy for my collegues to comprehend and check.
PS safe (automated) refactoring, like migrating to new codestyle can be as big as needed, and doesnt really require checking. But as you mentioned 23 commit and “context” attached to them - I take it as it was not the case )
PPS I have to admit, squashing works well with short-lived feature branches, CI/CD and instant releases. If you, for any reason, have different lifecycle (I bet its organisations’ processes/structure) squashing might seem like unnecessary or strange idea
Thanks for the input Andrew - I definitely had the feeling that PR was getting too big! The way I went about it was very TDD - authoring a test for the bug I was fixing, then getting it to pass, and then repeating that test + pass cycle until I had covered all of the corner cases. How would you recommend splitting that up? I wouldn't really feel comfortable merging a fix into master that I didn't feel was complete, so I'm curious what strategies you would have in mind!
I’m not sure if you will like this answer =) IMO if tests came out so big, component was also quite big, so maybe its possible to extact/isolate it and cover a small coherent part. Tests would likely to become smaller, and integration tests could be added in a separate branch.
PS yes it means refactoring before fixing a bug, and actually this is what I do too )
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.
Going along with what Alain was saying, this is something that confuses me too about why people like the squash workflow. I get uncomfortable at the idea of throwing away all that context! For example, my most recent PR at work had 541 additions and 26 removals across 23 commits. If I had squashed and ended up breaking something,
git bisectwould be useless for finding the commit that broke things, and if you're looking through the diff, it's much harder to figure out which logical idea in the commit message was responsible for which changed line.In the interest of building an understanding about why others work the way they do, what are some "pro-squash" benefits?
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.
your PR is too big
its not really checkable nor approvable - noone can hot approval button and consciously share responsiblilty for merging this to master. So go back drawing board, split it up! Respect your git history amd your coworkers time )
I do it all the time - an idea, or a feature first lands in a prototype branch (even TDDed one!) and the I split it to smaller branches that are easy for my collegues to comprehend and check.
PS safe (automated) refactoring, like migrating to new codestyle can be as big as needed, and doesnt really require checking. But as you mentioned 23 commit and “context” attached to them - I take it as it was not the case )
PPS I have to admit, squashing works well with short-lived feature branches, CI/CD and instant releases. If you, for any reason, have different lifecycle (I bet its organisations’ processes/structure) squashing might seem like unnecessary or strange idea
Thanks for the input Andrew - I definitely had the feeling that PR was getting too big! The way I went about it was very TDD - authoring a test for the bug I was fixing, then getting it to pass, and then repeating that test + pass cycle until I had covered all of the corner cases. How would you recommend splitting that up? I wouldn't really feel comfortable merging a fix into master that I didn't feel was complete, so I'm curious what strategies you would have in mind!
I’m not sure if you will like this answer =) IMO if tests came out so big, component was also quite big, so maybe its possible to extact/isolate it and cover a small coherent part. Tests would likely to become smaller, and integration tests could be added in a separate branch.
PS yes it means refactoring before fixing a bug, and actually this is what I do too )