If you are just starting on a project with multiple developers in the team, GitHub flow could be sufficient for your case. It basically works on the master branch, feature branches are created from master and then merged back into it after testing. The problem with this flow is every developer will have to test his branch separately, if you have a QA or staging environment for testing, each feature branch will have to be deployed on it separately, resulting in more waiting time for testing.
If your development team is growing and you are looking for more organized way to manage your git branches and deployment workflow, you must read Git Flow. Its being used and recommended by many developers and startups.
Basically git-flow relies on a
develop branch where all the feature branches are merged and a release candidate is taken out of it. This release candidate branch then gets tested, fixed and waits for its turn to go live(i.e. to be merged into
master). Hotfixes are directly merged to master. Every merge/commit to master is tagged. This workflow will work for most of the cases, but the problem is that
develop branch contains commits from all the feature branches currently being tested in staging environment, this means if at the end of your development cycle, one of the feature is not ready to go live, you will have to wait for the production deploy or take the feature branch out of
develop, both the options aren’t always feasible.
So here is a slightly modified Git Flow that we use at Appthority:
Proposed Git Flow
- Create feature branches from
- Merge your feature branch into
staging, no need for pull request here
- Do not merge staging back into your feature branch ever
- Resolve merge conflicts between feature and staging branch inside staging branch
- Deploy and test staging branch in staging/QA environment
- When the feature is QA verified, create a Pull Request for your feature branch to
- All the code that goes into release_candidate must be ready for production deploy
- Pull Requests for hotfixes go directly into
master, create hotfix branches from master.
- Now in this flow, only the QA verified feature branches go into
release-candidate, this means if there is a feature that didn’t get verified during the sprint can still continue to be tested in staging environment but won’t be deployed to production.
- Another benefit is that developers won’t get blocked on code review as the code review process can be done when merging the feature branch into
release-candidate, which happens at the end of the testing.
- Your staging branch might get a bit messed up with commits, you should delete and recreate(or force push) staging branch at the start of each sprint from
Let me know if you use this flow in your development, and how that works out :)