4 ms·
If you work on a very large projects with many released version and need to cherry-pick fixes to back-port, you'd be very, very, VERY glad that each branch got
by pierrebai 6y ago
If you work on a very large projects with many released version and need to cherry-pick fixes to back-port, you'd be very, very, VERY glad that each branch got squashed.
The story told in the article mainly shows to keep your PR focused. You can squash as long as you don't do 2-week-long 37-commits branches.
- couchand 6y agoMaybe... sure that's fewer commits to cherry pick. But when some reconciliation is needed to make a patch apply to different version branches, it's sure a whole lot easier to manage if the commits are small.
- MaxBarraclough 6y agoPerhaps we could 'have it all' if git introduced a way of bundling commits, a bit like code-folding in an IDE. The bundles could be expanded when you need fine-grain detail of development history, but by default would be unexpanded and would behave like a single big commit, avoiding the issue of always seeing overwhelming detail.
- stormbrew 6y agogit has that, it's called a merge commit. You can use `git log --first-parent` to see them unexpanded and then find what you want to expand. A lot of higher level tools don't expose this functionality but it's not like it's not there.
- cutemonster 6y agoIs there any high level tool that does expose that functionality?
- Vinnl 6y agoWhen rebasing my branches, most PRs will still be a single commit, some will be two or three. That's not that much worse than squashing, and far more informative.