Hey Ankit,

Thanks for taking the time to respond. I think you raise some good points.

With 1) Yes I think you're absolutely right that smaller commits would require temporary code as you say. Where we disagree is that I don't think this is a negative or bad practice. Adding temporary code is a fairly widely adopted strategy as an enabler for Continuous Delivery.

You might know about these already and just dislike the idea, but in any case here is some info on some of the practices I use for temporary code:

Keystone Interface: https://martinfowler.com/bliki/KeystoneInterface.html

Feature Toggles: https://martinfowler.com/articles/feature-toggles.html

Branch By Abstraction: https://martinfowler.com/bliki/BranchByAbstraction.html

This video (and channel) also gives a great explanation about this: https://www.youtube.com/watch?v=v4Ijkq6Myfc

With 2) - I think what you're describing here is the premise of "real" Continuous Integration. You are right that if someone commits bad changes they can halt everyone. That's why one of the rules of CI is:

"Fix Broken Builds Immediately" -https://www.martinfowler.com/articles/continuousIntegration.html#FixBrokenBuildsImmediately

CI requires discipline within the team to abide by this rule as well as a level of trust that developers will do their utmost to not break it.

But yes I agree - PRs do mitigate this. This is one of the reasons why I previously thought PRs where great - especially with merge checks. But what I've come to realise is that mitigating the fairly rare occurrence of someone committing team halting changes by using PRs doesn't return enough value compared with their costs .

With 3) I'm not 100% I understand your point but it seems related to 1). Instead of there being two versions of the code available via branches, I prefer there to be 1 version of the code which can be configured with different features/capabilities enabled - even in production. In the case of microservices, creating versioned endpoints can be used instead of config.

4) I'm not really sure about your point on this one. It seems to be more a case of how you are managing schema changes rather than anything to do with small commits? Ideally schema changes should be applied automatically when new code is pulled and the app run - so I don't see why PRs/branches vs small commits makes any difference?

I agree rebasing regularly definitely helps - but you're only updating your branch with what's already been merged in the mainline - if there are several developers working concurrently on their own feature branches, all of these branches are still diverging.