I'm exactly in this situation but I did opt for a slightly more complex though not necessarily more complicated workflow with Git.
The objective at first was learn the git way so I did some amount of exploring. then reverted to pretty much the workflow you described.
After a while this became difficult to work with as some situations arose also it gave me bad habits that would be hard to break once I join a team.
so I settled for the following :
- Local repository for working.
- Master branch as a stable trunk for the application
- One branch for each feature / refactor, basically one branch for each sizable changes that will be done.
- Merge back to trunk when the branch is stable and all tests pass.
I also setup a git hub account where I synchronize the trunk. This allowed me to easily start working on different computers. It was by necessity but allowed me to find bugs that were tied to the environment I was in which was not available on the other computers. So now I make it a habit to try a project on a different "virgin" system at least once. Saves me a lot of headaches when comes time to deploy to the customer.
- I tag every versions that makes it into github as a releasable version.
- If released to the customer I will branch from this version to create a second stable trunk for bug fixes declared by the customer.
The multiple branches at first seemed like overkill but it REALLY helped a lot. I could start an idea in a branch, work on it for a while and when I start running circles I gave up and started another branch to work on something else. Later an idea came where I would come back to the half baked branch and explore this idea. this overall made me MUCH more productive as I could act of flashes and ideas very quickly and see if it worked. The cost of switching branches with GIT is extremely low making me very nimble with my code base. That said I still have to master the rebase concept to clean up my history but since i'm all alone I doubt I really need to. Pushed it as "nice to learn".
When all the branching became complicated then I explored the log option to draw a tree of changes and see which branch are where.
Long story short, git is not like SVN, CVS or (brrr) TFS. Branching is very cheap and making mistakes that will wipe out work is actually pretty difficult. Only once did I lose some work and it was because I made my commits too big (see bad habits above). If you commit often, by small chunks git will definitively be your best ally.
To me git opened my mind to what source control really is all about. Anything else before was just attempts to get it, git is the first, that in my mind, got it. That said, I did not try other DVCS, quite possibly this statement could be widened to the whole family.
One last advice, the command line is your friend. Not to say that graphical tools are not good, quite the contrary but I really groked git when I dropped down to command line and tried it out myself. It is actually very well made, easy to follow with a very comprehensive help system. My biggest problem was being tied to the but ugly console in windows until I found alternatives.
Now I use both, Eclipse integration with Git to see what is going on in real time and do some operations like diffs, explore history for a file, etc. And command line for branching, merging, pushing, getting and the more complex log trees. some basic scripting and I've never been so productive with regards to source control and I never had so much control over my source.
Good luck, hoped this helped.