The flexibility of a distributed version control system can make deciding on a branching strategy somewhat difficult. Tons has been written on git workflows - one writeup that I love is Atlassian Blog's Simple Git workflow is simple. You really don't need much else if you're working on your own - but if you're on a more complex project or working with a team there are some additions I'd add to keep things organized. Here is a description of my typical naming conventions:
The development branch is where all functionality is gathered during a sprint. It is the second branch created during a project (after Master) and does not merge back to anything. No code should be committed directly to the develop branch (you should ALWAYS work on a branch), no code should be committed to develop without a code review, and develop should remain as defect free as possible. Treat develop as