Git process input for multi-sub branches & distributed development

Hello all,  I apologize for the long post… but I’m hoping to get some input on some process tweaks we’re trying to implement.  I’m a lead member of a fairly large development group using github as our repo (of course).  Currently all of our branching is “name” based and is all branched off master.  We delineate our types of branches by naming them “feature_xxx”, “project_xxx” etc…

I’m looking to re-org our repo for a smoother and more efficient approach to what we’re tryign to do, and I’d like some ideas and sanity checks.  So I have 2 questions

#1 our process.   
Currently we create branches for our changes, name accordingly and then when complete, we create pull-requests where another developer will review and approve, but conflict resolution happens closer to merging into master before deployments (after review) and so our deployments can take a while to prepare.  
I’d like each developer to manage their own conficts with process like this:
Create Branch --> Checkout --> Code --> Pull All --> Resolve Conflicts --> Commit/Push --> Pull Request --> Code Review --> etc…

The parts in bold would be the new steps happening locally for each developer . This way conflics do not exist in the repository and have already been resolved.

Can anyone see any glaring holes in this process?  In a prevoius life we did it this way using SVN and it worked fairly well, though admittedly our code review wasn’t as robust as we would have liked.

#2 our structure

As I mentioned before, we currently branch everything off of master.  We run a quasi-agile methodology shop with different development groups responsible for different areas.  We have (for the sake of argument)  3 distinct development teams

  • Quick Changes (simple updates less than 1-2 hours of coding)

  • Low Demand (less than 40 hours, to include bug fixes and/or hot fixes)

  • High Demand (project based 40+ hours)

I’d like to split these 3 teams into their own sub-branches to allow each to work their own pace and not have to be concerned with the items out of their scope.  Our quick changes dev team is our least experienced and should not be working in the same base repo’s as our project team (our advanced developers).    We have a releaes team that would be responsible for merging each of the 3 sub-repo’s back into the master but now instead of our release team managing 100’s of branches, each team can manage their own branch and then the releaes team can manage just the 3 subs.   This “should” allow us to deploy much quicker and help stay better organized.

Can anyone poke holes in either or both of the ideas above?  I need to know where the struggles will be.

Thanks so much.