Respectfully, I don't have the wrong idea, we'll have to agree to disagree here.
Your response is difficult to understand, but I'll try to respond to your questions.
Do you do big refactors along new features inside one merge or do you split in a feature merge and a refactor merge? And when you find a bug, do you mix the solution with other stuff or merge just the fix?
We don't operate in the context you're describing. Big refactors? Not a thing. We have a product team which scopes the work assignments for both feature development and bug fixes, and engineers review these assignments before accepting them to ensure the scope is feasible. Each work assignment is performed in isolation of its own branch and merged using a pull request. Nothing is ever committed directly to the trunk (main/master branch).
I get it, you work in branches and squash before merge. What I'm saying is that it doesn't matter. You still do features, fixes and refactors.
I'm not saying "big refactors", I'm saying from moving stuff around to habitual cleanups. I might relentlessly refactor stuff, but anyone need some refactoring here and there. And then there come a PR that is just too big and doing too much at one time.
We know people won't read a big PR, it's not really feasible and that's why it's better to do small and focused ones: refactors, feature, fixes...
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.
Respectfully, I don't have the wrong idea, we'll have to agree to disagree here.
Your response is difficult to understand, but I'll try to respond to your questions.
We don't operate in the context you're describing. Big refactors? Not a thing. We have a product team which scopes the work assignments for both feature development and bug fixes, and engineers review these assignments before accepting them to ensure the scope is feasible. Each work assignment is performed in isolation of its own branch and merged using a pull request. Nothing is ever committed directly to the trunk (main/master branch).
I get it, you work in branches and squash before merge. What I'm saying is that it doesn't matter. You still do features, fixes and refactors.
I'm not saying "big refactors", I'm saying from moving stuff around to habitual cleanups. I might relentlessly refactor stuff, but anyone need some refactoring here and there. And then there come a PR that is just too big and doing too much at one time.
We know people won't read a big PR, it's not really feasible and that's why it's better to do small and focused ones: refactors, feature, fixes...