Do you branch when you are building a new feature? Or only when you are making major changes? Or never? What about deployment, do you have a specific branch for Heroku or AWS?
https://www.atlassian.com/git/workflows#!workflow-gitflow
Previously, at my startup, we used long-running feature branches and merged to mainline as seemed reasonable.
Branches are pretty much the only reason to use git--and a damned fine reason they are.
- master (deployed/live version)
- develop (next version)
- feature/* (feature branch)
- feature/*/* (optional sub-branches for big features)
- fix/* (bugfix branch, may be off master if urgent)1) git checkout master
2) git pull // to fetch latest version
3) git branch issues/feature name
4) git checkout branch name
//...do work on branch...//
5) git add .
6) git commit -m "Description of commits"
7) repeat 5) and 6) until feature/issue is fully implemented/fixed
8) git push origin banch name
9) git checkout master
10) git merge branch name // only after the issue/feature is tested and debugged
11) git push origin master
Master
QA/Staging that tracks master (but can be merged to first for staging environment testing)
Feature/Release branch (once the project is stable, these are more granular) get merged into QA/Staging first.
(Never going back to the bad old days of 'branching' in SVN.)