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 a version of Master that hasn't gone through final QA yet.
Working branches come in one of three flavors:
- feature- - feature branches represent new features being added to the system.
- task- - task branches are for changes that are not adding new features... such as adjusting seeds or refactoring sections of the application
- try- - try branches are for experimenting with concepts that might not get used in the project
Working branches always branch off of, and merge back in to, develop. Only working branches which are complete, code reviewed, and release-ready should be merged in to the develop branch. This reduces the chances of defects inadvertently leaking in to the production environment.
Release branches are where functionality is gathered for the projects individual release environments. Whichever of the following branches you need can be created along with the develop branch at the beginning of the project.
The preview environment is used for internal staging of new features and QA. It leverages seed data designed to demonstrate developed functionality. Not all projects use this environment - but in cases where clients have access to our staging environment this gives us a place to push changes before we expose them to the client.
The preview branch will always branch off of develop and will not merge back in to develop directly (more on that when we talk about hotfixes).
The staging environment is used for QA and UAT. Wherever possible the staging environment will clone production data for testing purposes rather than using seed data. The staging branch pulls from develop (or preview if preview is being used) and will not merge back directly.
The production environment is deployed out of the master branch. As such the master branch should always be production-ready. Each release to the production environment should be tagged. Each tag should include a message with release notes where possible.
The production branch pulls from staging and will not merge back directly.
If defects are discovered in a release branch the correction is managed through a hotfix branch - which is prefixed with hotfix-. Hotfixes branch off of the furthest downstream release containing the defect and do not merge back. Instead the commits created during the correction are cherry-picked by the develop branch, the originating branch, and all branches upstream. As an example - if a bug is found in staging a hotfix- branch is branched off from staging. Code is created and committed to the hotfix- branch... then the generated commits are cherry-picked from the staging, preview, and develop branches.
Hotfix branches are blockers which should prevent a branch from advancing to the next release stage until cleared. The ticket associated with any defect discovered in production should be tagged "Defect Leak" in Jira so that defect density can be calculated for the project.