Never checkout the production branch
Or more specifically, never work off the production branch (it is ok to check it out for testing and/or patching). And here is why. You never know when or if you would be asked to work on a different requirement/fix while you are already developing something else. The production branch should only be used for testing the code that is about to go live or to make quick fixes (fixes that have a development cycle much shorter than the avg. timespan between two check-ins to the production branch).
The first approach you have mentioned is the one I have observed most commonly in enterprise settings. Here are the advantages:
- You can create as many different branches as you want for different features.
- You do not have to lose your work should you decide to abandon your task temporarily or have to work on a different task for a short while.
- Many developers have a habit of committing their changes to the branch so that they have a back-up (and to answer themselves "how the ... did I get here?" You obviously cannot take this approach with the production branch. If you use the Perforce system (I know you mentioned you are not) then you may be tempted to use the shelve feature but that does not get you out of situations I described in #1 and #2.
Some off topic advice on how to maintain dev. branches
I think it is a good practise to regularly merge the production branch to your dev. branch so that you do not have to undertake a massive merge task when you decide to merge your changes to the production branch. Another advantage of this practise is that if someone checks in a conflicting change to your changes to the production branch then you can find about that in your development cycle itself (assuming you test regularly while developing).
Another practise that you can follow to avoid messing up the production branch is to merge the production branch one final time with your dev. branch, test your dev. branch thoroughly to resolve/discover any conflicts (not just those that come up as line differences but even those that can come up as design level conflicts), and then merge your branch back to production.
Yet another good practise is to label the dev. branch with something that identifies the specific goal of that development task rather than just who owns that dev. branch (hence,
dev_notificationEnhancement and not