Group Created with Sketch. Group Created with Sketch.

Source Control

We use Git for source control and GitHub for hosting unless a client requests otherwise.

If a client has their own GitHub team and wishes to own the repository, there will be a fork of the project on the kohactive team that should be used for all issues, pull requests, comments, etc.

In each repository there will be a master and staging branch as soon as the repo is created in GitHub.


This should always reflect the code that is in production. CI (continuous integration) and CD (continuous deployment) should be used whenever possible to ensure that code merged into master is deployed to production as soon as possible.

  • Developers should not ever push directly to the master branch
  • The only pull requests against master should come from the staging branch
  • If a hotfix needs to be merged into master without going into staging first, a pull request should be created against master. The developer who merged the pull request is responsible for rebasing the staging branch afterwards


This should always reflect the code that is in staging. Most pull requests will be created against this branch. This branch should use CD to deploy to a staging app where user stories and bug fixes can be verified in an environment as close to production as possible.

  • Developers should not ever push directly to the staging branch
  • Developers should submit pull requests against the staging branch
  • Developers should regularly rebase their local branches against staging to keep the branch from having merge conflicts

Developers can decide whether or not they want to fork a project or work on an upstream branch. Upstream branching is allowed and sometimes recommended in order to support continuous integration via Codeship.

When upstream branches are used it is courteous to delete your branch after it is merged to help keep the number of upstream branches reasonable.

The following labels should be added to each repository to help quickly determine the status of a pull request:

Work in progress: This PR should not be reviewed or merged

Awaiting API: This PR can be reviewed, but not merged until the backend is ready (usually an API endpoint is needed)

Awaiting FE: This PR can be reviewed, but should not be merged until the front end is ready

Awaiting Review: This PR is ready to be reviewed and, if approved, merged into staging

How we Git

Each feature, bugfix, enhancement, and refactor should have a corresponding branch prefixed with the following:

"feature/": A new feature that is being worked on. This, ideally, adds functionality that did not previously exist in the application.

"patch/": Updates to a previously committed feature that is already in the master branch

"bugfix/": A fix to an existing feature or to the core functionality of the application.

"enhancement/": This pull requests makes some modifications and/or improvements to existing features and functionality without changing the

"refactor/": This pull request should not affect the functionality of the application, but should be used when code is rewritten or reorganized

Other prefixes are acceptable if the purpose of the branch does not fit into these categories, but a branch name should always be prefixed (if nothing else, this helps us to distinguish between the default branches of master and staging)

Our Git Workflow

Our git flow process should look like the following:

  1. Checkout the staging branch and make sure it’s up-to-date by pulling from the upstream repo
  2. Create a new prefixed branch, off of the staging branch
  3. Write the code, committing as frequently as possible
  4. Submit a pull request to the staging branch

When submitting a pull request, make sure address the following:

  • Give the pull request a descriptive title (please don’t leave the prefixed branch name as the title)
  • Write any steps that might help to review the code as the initial comment of the pull request
  • Assign the team lead (and any other developers) to review the pull request

If changes are made to the upstream staging branch while your branch is still in development, follow this process:

  1. Checkout the staging branch
  2. Pull from the upstream
  3. Checkout your feature branch
  4. Run git rebase staging
  5. Resolve any conflicts
  6. Push your branch with the force (-f) flag

It’s best to do this as soon as possible after the upstream has changed to keep the number of conflicts minimal.

Sometimes it’s difficult to know which changes to ignore and which to keep when resolving rebase conflicts. If you run into a conflict you are not sure about, contact the team lead and they will help you to resolve it.