This is very similar to a successful git branching model that we've employed in my workplace - it works wonders for us (though we differ slightly from your branching a little, and put the git tag on production server so that devs don't patch live and update git via production server (and possibly fubar the branches)).

When developing

Your proposed method is great. Every developer has their own workplace (on the server) and they have their own [feature] branches - this will be great help as you'll be able to track what features are in development, where in the development lifecycle they are, and who is responsible for them (though if you adopt agile workflow, you'll know this; it's nice to know when you look back in the past).

Developers having their own [feature] branch when developing will allow you to work on different features without overwriting each others work.

This stage is fine, no caveats

When testing

Testing can become confusing, because what if you find a major bug that needs patching but feature X is ready to go live? Who is responsible for the testing?

Fixing a bug during testing

When you have your testing branch on the test server and you find a bug that needs patching, it can be addresses 2 ways;

• Checkout of testing branch into a bug fix (bf-) branch. When there is a bug, usually I create an issue detailing what needs patching and name the bug fix branch after it (ie: opened issue #293, the branch will be bf-293). This will greatly help you track what was fixed.
• Directly patch the testing branch.

Testing multiple features

Again, very easy to do with your proposed branching model. Ensure you create a pull/merge request to document what code was changed (this has saved my bacon many times in the past) and at what stage in the products lifecycle a particular feature went into testing and production.

Once all features have been merged into the development branch, ensure you create a fresh testing branch (I usually name these release candidates. Ie: we are testing v2.42, I will name this testing branch rc-2.42) and push up to the testing server.

This stage is fine, no caveats

Go live

Going live with git is great. Once you're happy with your test results and ready to push live, ensure you open a pull/merge request so that it's documented what is going live when (as previously mentioned).

! If you fixed some bugs during testing then make sure you merge the testing branch back into development. You don't want things that are in master and not development - things will get messy and confusing very quickly.

Once merged into master, ensure you tag it to create a point in time to roll back to (I'll explain later). When you go live, ensure you checkout into the new tag so that you cannot patch live without going through the git procedure.

When you've gone live, I like to create a post in the wiki to document the new version and link the pull/merge request. It will be much easier to track what went live.

Why use the tag?

Tagging creates a point in time that is very easy to rollback to should something go terribly wrong on the production server. It also manages your visioning and nice to look back in time to see what went live when.

Conclusion;

• Your branching model is fine
• Make sure you open pull/merge requests before merging
• Ensure you tag your master branch
• Ensure you document the push to production (in the wiki)