Let’s say there is a team of five developers and one manager. Manager supplies tasks, developers make them happen. Some developers are more confidant, so they push their code stright to master. Some developers are not so confidant, so they develop new features in feature branches and submit pull requests for a review. Some features need managers approval, so we need to have QA server for him to be able to look at it. After number of features accumulated in master branch, manager decides that there should be a production release.
All code ends up in master branch, either stright from developer’s machine or after pull request gets merged. Master branch ideally should be deployable at any point in time. You need to have a good test suite to be confidant about that.
All the work going in feature branches, which get merged into master branch after code review. Github pull requests is a convenient way to do that. If your team is less formal, everyone can push stright to master.
Sometimes manager or client needs to look at how particular feature works. You can have QA server for this and deploy either your feature branch or master branch on it.
Production has it’s own branch. At any point in time, you can checkout to production branch and see what code is currently running on production server. Also, having dedicated branch makes it easy to supply bugfixes. If something goes wrong, you make a fix in production branch, cherry pick it back to master and redeploy production.
Create QA and production deployment environments, which mainly going to be different by branch they are deploying and server ip address. You all set, just run
cap qa deploy to deploy to QA server or
cap production deploy to deploy to production server.