What’s the limit of changes that can go into a one commit? We have this one adding to fields to variants and products https://github.com/solidusio/solidus/pull/6097/files Would you prefer four commits of is one enough given the limited nature of the change here. • Migration • model • API • Backend

There's usually no such thing as too many commits. https://www.aleksandrhovhannisyan.com/blog/atomic-git-commits/

Migration, Model and model tests can be one commit. api and backend can be separate commits, but when the change is small and the backend needs the api anyway, put it into one commit. rule of thumb: things belong contextionally together. atomic means: it can be reverted so that it does not break tests.

Maybe it makes sense to think about why we want atomic commits that make conceptual sense. As maintainers, we want pull requests that are easy to review. Here's how we review: 1. When we review PRs, we often first read the PR description. It's good if its concise and - if there's a lot of discussion on the PR - up to date with what's in the PR. Especially as a second reviewer we don't want to wade through endless comments to find why the PR description does not match what's in the PR. 2. The second step is - especially for even mildly complex PRs - going through the pull request commit by commit. We do that so we can understand what changes are made in that PR. Ideally, the commits in one PR make sense like a story. If you think about commits telling a story (or pitching your feature if that's your vibe), it shouldn't be too hard to also write a short commit message detailing the why for this commit. This includes any naming that's introduced or changed. We want to look into your brain. 3. For every commit, we check whether code introduced or changed in that commit has meaningful, maintainable tests.

Very well said! 🙏🏻