Really? A new branch for every change? Never heard anyone doing that.
That's pretty much the basic rule when using git. You could even go as far as saying "master is for merging, not for developing". Just make it your goal that master is always in a decent state, builds and isn't a messy construction site.
We're using Gerrit at work, which requires all changes that get pushed to be reviewed before they get merged to master (plus, a build is automatically started to verify the project still compiles... in the future, we might make unit tests still passing a requirement as well).
We generally work on on our own local master branch day to day, but origin/master (the master branch on the central repo) is kept in a working state.
When you're happy with the state of your own local master branch, we run a script that pushes to a temporary remote branch and notifies the build server. That server then compiles your code and runs the game through a bunch of automatic tests on every platform. If all the compilation and testing passes, then the server pushes your changes into origin/master.
That's basically just a fancy system to ensure that no one pushes to origin/master unless their code actually compiles and has been tested first. You could do the same with pure discipline 
Also, if you want to be nice to your co-workers, you clean up your own local master before pushing. e.g. if you've done a series of small commits relating to the same feature, you might use git rebase --interactive to squish a few of them together.
We only really use branches if you're working on a long running task, which can't be committed in part because it would breaks things, and multiple people have to collaborate on finishing it.
