Kiran Satya Raj the thing is git branches are widely over used. They where created for ope source where you dont know and cant trust the person that creates a commit, so you review the code to validate no malicious code is added. A team is not a 0 trust environment, and PR are just used as a peer review process (normally just in an egotistical way), but is the most ineficient peer process of all as the feedback loop is after work is finish and is async (pair programming, desk checks, etc are alternatives, and dont need branches). Also merge conflicts even if it sounds counter intuitive are more common and difficult to solve in branches than in trunk based development, because the smaller the commit and higher the frequency of merging the divergence of the code is also smaller. Also no person in a team develops in isolation so what works in a branch might have side effects on the trunk. So pushing continiously into the trunk and do CD helps solves issues faster because you will know what specific lines of code broke and not chacing down a bigger set of merged functionalities. Does this mean I continiously push broken code into production, yes, and personally i dont mind as is not an issue because i have the tools to make sure it does not affect users, my code is either branched by abstraction or behind a feature toggle that decouples release time from activation/deactivation time, and i get notfied that things broke by alarms tide to my metrics.

Alvaro This is wholesome!! I particularly was to mean it for the opensource workflow, I just got started with contributing to open-source projects, so when people commit to the project, it needs to be reviewed or may be requested for changes, before it's merged into the main branch, hence the way I mentioned the use of branches gives the wrong idea, so I assume rephrasing that to the open source scenario would be better, right?