It depends on the project. The biggest thing is to assess where the team is at. I just left a project where the team had serious issues and the leadership did n

It depends on the project. The biggest thing is to assess where the team is at. I just left a project where the team had serious issues and the leadership did not have the desire to fix it...IE: a tech lead that was more of a mid level dev running a command and control style thing. The team, with more experience, did not have a say in the architecture, what they got to work on etc.. All devs had to get their commits past the mid-level lead, the lead would reserve most of the fun and hard stuff for themselves and leave the scraps for the rest of the team. The lead had multiple silo'ed efforts and, as a result, had a higher number of commits etc. on code base partially because they were constantly declining PR's from the rest of the team to do it their way. Now if you have a team that is actually open to your ideas things are VERY different. I've worked on them and they are amazing. The key thing is to evaluate where they are at and apply what is going to work for them. The biggest thing is to avoid the one size fits all approach. With the original comment for this thread, my biggest issue out that gate with their approach is that you are using a lot of branches which negates the benefits of CI etc.. Why not instead try to figure out how to reduce branches and have more people checking in working code to dev with unit tests?