We’ve used multiple other branching models with some success, including the Gitflow branching model but we found a better way for remote teams who want to deploy continuously.
In its simplest form, this model branches features off master
, integrates and tests them on develop
, and then merges them back into master
. Below we’ve included some important rules and tips, but don’t let that fool you into thinking this is complicated.
Benefits of the continuous deployment branching model:
- Allow all features from multiple team members to work their way to production simultaneously and continuously as they’re completed
- Minimize the possibility of a feature becoming a blocker for other team members, features, or releases
- Prevent unproven code from ever accidentally or maliciously getting to the production server and from being unknowingly propagated to other features
- Allow multiple features to be tested on a QA server (or staging server) at the same time while allowing for any changes found to be corrupt to be wiped from all environments quickly
- Give team leaders more visibility and control over how and when changes move to production
- Improve the clarity of merge conflict resolutions and decrease the likelihood of code code loss
- Make it easier to start, stop, and re-start new features.
Two Deadly Serious Rules
Ok, they’re not deadly except to team mojo, but here are two rules that you should never forget:
- Never merge the
develop
,qa
, orstaging
branch into any other branch, these branches are always assumed to be corrupt because they’re used to test all features that can become corrupt. - Always branch new features off the
master
branch (e.g.git checkout -b INSERT_FEATURE_BRANCH_NAME
) and keep them up to date by merging in master often.
Branching Summary
First, branch your feature off of master
. Make your code changes on your feature branch. Create a pull request into develop
. If there is a conflict, remember that you’re conflicting with another feature branch, not develop
. Send a link to your pull request to your developer lead for a code and user review. The develop
branch is used to test changes on a QA server and can be corrupted and/or thrown away at any time (hence one of the deadly rules above). Once the quality of your feature is assured, we merge it with master
and deploy it to the production server.
Prerequisites
- You’ll need to make sure you have Git installed on your terminal
- Then, clone your code locally (e.g.
git clone git@github.com:vuejs/vue.git .
) - You’ll start with a
master
branch and create adevelop
branch offmaster
.
Branching Steps
Let’s imagine you’ve been assigned issue #999, a bug squashing change requested by a customer.
- You’ll need a new branch to keep all your changes together, we call this a feature branch.
- Always branch features off the
master
branch (e.g.git checkout master; git checkout -b 999-bug-squish;
).- Note the issue number prefix (e.g.
999
) on the branch name helps connects your feature branch to the change request. - In a perfect world, each issue should have only one branch to make it easy to move your changes through testing to production.
- Note the issue number prefix (e.g.
- Make your changes on your feature branch and commit them.
- Pro tip: draw a clear connection between your changes and the issue that requested them by including the issue number in the commit message (e.g.
git commit -m '#999 squashed some bugs'
). Your team will love you for this. - Pro tip: before committing, run
git diff
to make sure you’re not committing unnecessary changes.
- Pro tip: draw a clear connection between your changes and the issue that requested them by including the issue number in the commit message (e.g.
- Merge
master
back into your feature often to make sure it is up-to-date (e.g.git checkout 999-bug-squish; git pull origin master;
). - Push your changes back to the origin (e.g.
git push origin 999-bug-squish
). - Create a pull request (PR) into
develop
- Remember, only proven code makes it to
master
and it must be proven on the corruptibledevelop
. - Pro tip: grab a link to the original issue #999 and include it in the pull request to make sure everything is interconnected.
- Pro tip: if your changes affect what the user sees (i.e. the view), include a GIF of the new view to make it easier for the reviewer to review.
- Remember, only proven code makes it to
- If your pull request has a conflict, don’t break one of the deadly rules…
- Remember, your conflict is not with
develop
, but with another feature merged intodevelop
ahead of yours. - Pro tip: first, try merging in the latest from
master
. The conflicting feature may already be merged intomaster
and syncing your branch could save you a lot of time. - If merging in
master
doesn’t help…- Find the third party branch that conflicts with yours and reach out to your lead developer to make a decision whether you should make your code dependent on that branch.
- Pro tip: find the conflicting branch by using the Blame/Annotate feature of Github/Bitbucket. This is where good commit messages from step #3 can come in handy.
- Pro tip: if you do make your branch dependent on another feature branch by merging it into yours, note this dependency on the original issue #999.
- IMPORTANT: the most common mistake when resolving a merge conflict is to delete another developer’s code. You need to be thoughtful about why the conflicting changes were made and double check with the other developer before deleting anything.
- Remember, your conflict is not with
- One last thing before you submit your pull request for review, do a mock review yourself.
- Both Github & Bitbucket provide the ability to review and comment on your pull requests. Make sure all your changes are needed and wanted, use comments to explain unusual looking code, make any last minute re-factoring.
- Submit for review by comment on the original issue #999 and include a link to the pull request
- Pro tip: if the changes require special “steps to go live” or unusual “steps to review”, make sure to include those as well when you submit for review.
- Your feature branch’s code changes are then reviewed, merged into
develop
, and deployed to the QA server for further testing by the customer. - Once approved to production, your branch is merged into
master
and deployed to the production server. - Whenever
master
changes, you’ll need to merge it back intodevelop
to keep develop up-to-date- If
master
ever has a conflict withdevelop
delete thedevelop
branch and create it again as a copy ofmaster
- If