Yes it has it up and downs. But it also helps me and my team to enforce smaller patches since they land as one anyways. And other teams in my company follow the open PR and develop the next 2 weeks on it and merge in full. There is so much garbage in all these commits no one ever wants to get back to. Good luck bisecting on of these histories.
How independent are those commits? If I'm developing a feature that has distinct but dependent changes, then the rebased/squash pattern doesn't work as well. Submitting in a single PR means that those distinct changes all get squashed away. Submitting in a series of PRs keeps the history, but means that the have commits on main have different ids, and so I need to keep using `git rebase -i` to remove the corresponding commit from my dev branch whenever one gets merged in.
GitHub is pretty smart nowadays. If you propose a series of PR on top of each other, GitHub will change the base when it the base of the second PR got merged and so on. There is sometimes the need to rebase but I have generally no problem with it. Mind that I don’t propose this workflow with teams that also have non tech members like artists because these Workflows bring too much friction. But I keep my changes as independent as possible. All running with tests to cover the added/changed code.
