I don't do atomic commits and I disagree with the emphasis placed on the practice. As software developers, our focus is to build and ship products, not over-analyze micro-practices like commits.
Atomic commits are irrelevant to some of us in the industry because we leverage squash on merge, which condenses all the work done in a feature or hotfix branch into a single commit on the main trunk. This keeps the main trunk leaner, and also reduces the headaches of reversing single commits that are actually dependent on the commit order to properly function.
At least what I do is not about over analysing commits, but the code before I commit it. It's just as much care as with naming functions, variables and writing comments.
In your case of squashing on merge, I can still see it as "bigger" commits.
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?
I know for experience that mixing too much in one single merge is very taxing for reviewing, if you give me a refactor only merge I expect a lot of changes that don't actually change what the code does. Meanwhile a feature one might have or not lots of changes, but they should be focused on one thing. Same for a fix one.
Not sure if there's a "conventional merges", but depending on how you're naming the merges, you can still find out something!
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.
I don't do atomic commits and I disagree with the emphasis placed on the practice. As software developers, our focus is to build and ship products, not over-analyze micro-practices like commits.
Atomic commits are irrelevant to some of us in the industry because we leverage squash on merge, which condenses all the work done in a feature or hotfix branch into a single commit on the main trunk. This keeps the main trunk leaner, and also reduces the headaches of reversing single commits that are actually dependent on the commit order to properly function.
There's one point you might have the wrong idea.
At least what I do is not about over analysing commits, but the code before I commit it. It's just as much care as with naming functions, variables and writing comments.
In your case of squashing on merge, I can still see it as "bigger" commits.
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?
I know for experience that mixing too much in one single merge is very taxing for reviewing, if you give me a refactor only merge I expect a lot of changes that don't actually change what the code does. Meanwhile a feature one might have or not lots of changes, but they should be focused on one thing. Same for a fix one.
Not sure if there's a "conventional merges", but depending on how you're naming the merges, you can still find out something!
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...