I wouldn't have two separate branches for bugfixes and then one for new features - as you noted, it can get hairy. Personally I find the git-flow model very straightforward.
Do normal feature development and bug fixes on the develop branch; save master for production releases. When it's time to make a release, cut a release branch (e.g. r/1.0.1) from the develop branch. Bug fixes that are made on that branch should also be merged into develop. Once the release is made, merge r/1.0.1 back into master and develop and continue on as normal.
The problem is that between a feature being ready and it going into production there is a certain amount of QA/tweaking that goes on. Before I was running into issues where I couldn't fix a much smaller bug than the new functionality due to not having a branch for that. The flow handles that with hotfixes, which I guess works well.
I do think the numbering is excessive however: web software releases so often on a one man team it's mostly extra work.
Do normal feature development and bug fixes on the develop branch; save master for production releases. When it's time to make a release, cut a release branch (e.g. r/1.0.1) from the develop branch. Bug fixes that are made on that branch should also be merged into develop. Once the release is made, merge r/1.0.1 back into master and develop and continue on as normal.
Also see: https://github.com/nvie/gitflow