I don't get the part about the small commits. To me a commit could be massive and that's alright, provided it introduces some major feature, while a fix could a one-liner. It really depends on the situation.
replies(4):
In general, the biggest hurdle engineers need to overcome is to believe it is possible and then simply start thinking in terms of delivering value with every single branch (hopefully user value, but a refactoring counts too), and what are the small steps that get us there?
The benefits are amazing:
* Changes are likely to be limited to only one "thing", thus making them both lower-risk and easier to review and QA
* With every step shipped to production, you learn if it is providing the benefit you are looking for or if you need to pivot
* You are not developing a feature branch while "main" moves at the same time, and wasting time on keeping up with it
* If the project gets stopped 3 months in, you have still delivered some value, including those in-between refactorings
* Your customers love you since they are seeing improvements regularly
* There is never any high-risk, big "release" where you need to sit around as 24/7 support and wait for bugs to rear their heads
I am happy to give some guidance myself: what is the "major feature" you think can only be done with a single, large change all at once? (I've done huge DB model changes affecting 100Ms of rows with no downtime, merged two "subapps" into one, migrated monoliths to microservices etc, but also built new full-stack complex features with branches with diff size being less than 400 lines for each)