New Repositories

Git repos represent projects. Every project/repo should have a maintainer. This maintainer is responsible for managing branches, merging to master, and deploying.

Read Me

Every repo should have a README. That should include the following at a bare minimum:

• Site title or project name
• Maintainer/author name
• Installation instructions for Local
• Deployment instructions for Production

Git Flow

This is how we use git for development and releasing. This coincides with how we set up environments, so be sure to familiarize yourself with that as well.

Branches

There are 3 types of branches, master, dev, and feature branches.

Feature

This is your development code. There should be a corresponding issue for each branch, from whichever issue tracker we’re using, eg) Wrike, Trello, Github Issues, etc.

Always branch off of master to create this branch so that it’s self-contained. The branch name should have 2 to 3 parts to it, separated by /. The first required part is whether it’s a fix or new feature. The second optional part is the slug or id of the issue tracker. The third part is a short readable slug describing the issue. Here’s an example:

new/23/some-new-feature-to-build

Dev

Once you’ve finished your feature, push your branch and also merge it to dev branch. This branch is always named thusly, and should never be committed directly to, only merge in your feature branches. The purpose of this branch is to be collection of all features working together. This is often set up to deploy automatically on a dev server somewhere to review.

Master

This is the most stable code that will be deployed to production sites. It doesn’t necessarily contain all code from dev, since sometimes we only want to release a subset of feature branches and not everything. Therefore master is never ahead of dev. This is often set to auto deploy to a stage server for QA (not active development) before being manually deployed to the production server.

Maintainers

There should be a maintainer of the code base that does the merging to master and deployments. They should periodically, usually after a release, clean up all of the feature branches that have been merged to master and deployed and working on production.