Use the master branch as your development branch and create release branches for performing bug fixes.
Any new features will go on master during the development window (either committed directly or as topic branches with pull-requests, up to you -- not shown in graphic). Once all your planned features are implemented, enter feature freeze, and perform testing. When you're happy, tag the release on master as v1.0.
Over time your users will find bugs in v1.0 so you'll want to create a branch from that tag (e.g. name it after the release 1.0) and fix those bugs in the branch. When you've got enough bugs fixed that you think it warrants a new release then tag it as v1.0.1 and merge it back into master.
Meanwhile a new development window can be happening on the master branch which will eventually be tagged as v1.1.
Rinse & repeat.
This follows Semantic Versioning numbering logic.
---------(v1.0)--------------------------------(v1.1)-----------------------------> master
\ \
---(v1.0.1)---(v1.0.2)---> 1.0 ---(v1.1.1)---(v1.1.2)---> 1.1
