Skip to content
This repository has been archived by the owner on Feb 1, 2019. It is now read-only.

GitHub workflow

jmarin edited this page Nov 18, 2014 · 1 revision

GitHub Workflow Guide

This summary guide provides details on how we use GitHub for development in this project. For more details on using Git and GitHub at CFPB, please refer to the developer manual.

The HMDA Pilot project has two week sprints, with one milestone every other sprint (one milestone per month). We follow the GitHub pull request workflow, with the following considerations:

  • Developers are required to fork the main repository and work on their account when adding features, fixing bugs, etc.
  • When a feature/bug/enhancement is ready to be brought in, a pull request is issued to an integration branch, named after the current milestone (i.e. pull request against branch milestone1).
  • It is required that someone else review the pull request and perform the merge when the code is ready.
  • At the end of every milestone (and sometimes more frequently) we will merge the integration branch with master. The master branch should always be able to build and execute, passing all tests.
  • Integration branches will be deleted after the corresponding milestone has been achieved (time based) and their code is merged to master

Example workflow:

  1. Developer forks main repo, project is currently in milestone1
  2. Developer creates a feature branch to work on an issue, pushing changes as necessary to this branch in their personal fork
  3. When ready, developer issues a pull request against milestone1
  4. Developer 2 reviews pull request and merges as necessary.
  5. At end of sprint (or before if an interim build is desired) milestone1 branch is merged to master, and mileston1 branch is deleted
  6. Release artifacts (zip, etc) through GitHub, create milestone2 branch, repeat process
Clone this wiki locally