Branching strategy

This is my branching strategy, which should work well for any development from a single developer to a small team.
The goal for the strategy is to minimize branching, and administrative tasks.
For large team development a completetly different approach is needed.

Here is the strategy described in words:
* Use Master branch as development branch.
* When it is time for a release,
- tag the commit, ex v1.0
- create a branch, ex v1.0
* Continue development on Master branch
* Make corrections/fixes for v1.0 release on branch 1.0
* Merge fixes back to development/master branch (if needed)

Some ascii art to show the workflow

 tag     1.0                             1.1
 ---------*------------------*------------*------------------*-------> Master
           \                /              \                /
            \              /                \ v1.1         /v1.1.1
             \ v1.0       / v1.0.1           -------------*------> 1.1
              -----------*-------> 1.0

Here is a small example

git init
echo "some text" > a.txt
git add a.txt
git commit
echo "some more text" > a.txt
git commit -a
git tag -a v1.0 -m 'version 1.0'
git branch v1.0
git checkout v1.0
echo "third row of text, on new branch" > a.txt
git commit -a
git checkout master
echo "third row of text on master branch" > a.txt
git commit -a
git merge 681d9911379f4bed16903c876b72243e3de7d4dd
git log --graph --pretty=oneline --abbrev-commit

The resulting git tree.

* 0ffb123 Merge commit '681d9911379f4bed16903c876b72243e3de7d4dd'
|\
| * 681d991 Text added on v1.0 branch
* | 5c8800b Third row of text on master branch
|/
* 0496fc8 Added a second row of text to a.txt
* f5251a8 Initial commit, adding file a.txt