VIP Go platform specific
This document is for sites running on VIP Go.
- Benefits of Using GitHub Flow
- What About Non-Production Environments?
- My code is approved, how do I deploy?
- Scheduled Reviews for large changesets
- How do I create a Pull Request?
- How do I test a colleague’s PR branch on my local machine?
- I merged and deployed my PR. How do I get started on my next feature?
- Oh no! I committed to the
- There were some updates to master and now my PR branch is out of sync. How do I update my branch to get the latest version of the site’s code?
- Someone else pushed updates to my branch and now git is complaining when I try to push up my changes.
- Git Tools & Resources
This code review workflow uses GitHub’s pull request (PR) functionality, and the associated approval workflow for PRs that GitHub provide.
Instead of everyone pushing directly to the
master branch, we’re using GitHub Flow, a branch-based workflow that streamlines reviews and deployment.
When you want to work on a bug fix or new feature, create and switch to a new branch locally. Make changes, commit, and occasionally push up the branch. When your branch is ready for VIP review, create a Pull Request against the `master` branch (for production sites).
Pull requests to `master` surface as a new review request in our internal review queue. The VIP Team will then review the PR directly on GitHub, and suggest any changes by leaving comments. Your team will go through and make any necessary changes, and when you’re ready for another round of review, “dismiss” the review. This process continues until there are no outstanding issues, at which point the VIP Team will “approve” the request. Communication for these status changes will flow through your GitHub repository.
Once the Pull Request is approved by the VIP team, you may merge it to `master` at your convenience. Merging to `master` triggers an automatic deploy to the production site.
If there are any issues with the deployment, GitHub provides an easy, one-click option to “revert” Pull Requests (GitHub documentation on reverting a pull request).
GitHub allows any number of approvals against a Pull Request, so your team can also utilize this approvals workflow if desired. Please note, however, that GitHub will allow you to merge your PR to
master once the PR has any approval from either the client or VIP team; please wait for approval from a VIP Reviewer before merging the PR to
Summary of the new flow #
- Create a local branch.
- Commit, test, push.
- When ready for review, create Pull Request (which initiates a review request).
- VIP Team reviews Pull Request.
- If changes are required, VIP marks Pull Request as “Request Changes”. When your changes are implemented, you “Dismiss Review” to request another review.
- If code is ready, VIP marks Pull Request as “Approved”.
- You can now merge the Pull Request to `master`, which triggers a deploy.
Benefits of Using GitHub Flow #
GitHub’s code review tools are excellent. There are many benefits to your team and to VIP in using GitHub directly for code review, including:
- Inline commenting on code, making reviews easier to follow, and sharing feedback more direct.
- More control over deployments to production. You can choose to merge when you’re ready for the code to be deployed, allowing you to stage changes and deploy when your team is ready.
- Simplified rollbacks/reversions with the GitHub one-click method to revert Pull Requests.
What About Non-Production Environments? #
Your non-production site(s) and workflow(s) remains as-is. For example, merges to the
develop branch deploy automatically to the
develop site without VIP involvement.
We highly recommend following GitHub Flow for non-production environments as well. An example workflow with a
develop environment could look something like:
- Create local feature branch (
- Develop, test, commit changes.
- Push up changes to new remote branch.
- Create a PR from the remote
- (Optional and recommended) Internal team code review.
- Merge PR and test on
- If everything looks good, create a PR from the remote
- Proceed with VIP Code Review.
My code is approved, how do I deploy? #
Once a member of the VIP team has approved your code, the next step is to merge your code to
master which triggers this code to be deployed on the site. Typically deployment takes less than ten seconds.
Scheduled Reviews for large changesets #
Large changesets and PRs take longer to review, and can be more complex. If a changeset is larger than about 1,000 lines of code it may need more time than our traditional review/deploy workflow facilitates, to give it the proper attention it deserves. In these cases we may mark your PR as
[Status] VIP Scheduled Review, and set a date when we can assign an engineer to spend the required time to review your changes; alternatively you could break the PR up into smaller, more atomic commits, and submit a number of smaller PRs.
git Scenarios #
How do I create a Pull Request? #
GitHub has an excellent guide that covers this in detail: https://help.github.com/articles/creating-a-pull-request/
How do I test a colleague’s PR branch on my local machine? #
You can create a local branch that “tracks” a remote branch. Find the branch name for your colleague’s PR then use the following to checkout the branch locally:
Let’s say the branch is called “add/new-feature”:
git checkout -t origin/add/new-feature
You can now test the changes in your local environment. You can also commit, push, and pull directly to/from the branch as well.
More details on tracking branches at http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html
I merged and deployed my PR. How do I get started on my next feature? #
Congratulations on your successful merge and deploy. Take a moment to celebrate, first! 🙂
# Switch back to master git checkout master # Get the latest changes git pull origin master # create a new branch and continue development
Oh no! I committed to the
master branch! #
We can fix this.
You first need to figure out how many commits you need to move over to the new branch. Let’s say it’s 3 commits.
# Create a new branch with your commits included git checkout -b add/feature # Switch back to master git checkout master # Delete the commits from the master branch git reset --hard HEAD~3 # Go back to your new branch git checkout add/feature # Continue on with your development
As another example, if it was 1 commit, your reset command would change to
git reset --hard HEAD~1
There were some updates to master and now my PR branch is out of sync. How do I update my branch to get the latest version of the site’s code? #
# Switch to master git checkout master # Get the latest updates git pull origin master # Go back to your working branch git checkout add/new-feature # Rebase the changes from master into your branch git rebase master
If you run into conflicts, GitHub has excellent resources on how to resolve them from the command line:
If you get errors about fast-forwarded branches, you can force push to the branch to get your changes up to the remote branch.
git push --force origin add/new-feature
Someone else pushed updates to my branch and now git is complaining when I try to push up my changes. #
# Pull the changes from the remote branch and rebase them locally git pull --rebase origin add/new-feature # Fix any conflicts that come up # Force push to the remote branch git push --force origin add/new-feature
Git Tools & Resources #
- https://help.github.com — official GitHub documentation.
- http://gitready.com — learn git one commit at a time.
- https://git-scm.com/book/en/v2 — the entire Pro Git book.
- https://sethrobertson.github.io/GitFixUm/fixup.html — a choose-your-own-adventure-style guide on fixing git mistakes.
- http://ohshitgit.com — how to get yourself out of bad situations in git.