Pivotal + VMware: Transforming how more of the world builds software

Git Branching

git

It is increasingly becoming more difficult to keep up with changes. Far too often there are dependencies on projects with simultaneous work going on and once those changes are committed, you are forced to update and build all dependent projects, which is time consuming and breaks the flow of the sprint.

Current Environment

  • All projects are stored in 3 or 4 massive repositories
  • All projects share the same version number
  • All dependencies across applications are dependent on Snapshot releases, stored locally in the users ~/.m2 directory
  • Work must continue outside the sprint
    • When commits to develop are made outside the sprint, a single update requires all snapshots to be updated and rebuilt

Future State

  • Each project lives in its own repository
  • Each project is independently versioned
  • Each project has a target in Nexus
  • Each project produces snapshots and are also stored in Nexus

Action Plan

Until the Future State can be achieved, the follow is to be enacted and adhered to by the dojo so as to minimize the effects of external changes as well as propagate internal change performed by the members of the sprint.

  1. Each of the top repositories need to create a dojo-specific branch, called pcf_xyz_develop
  2. For each story that warrants a feature branch it is to be derived from pcf_xyz_develop
    • If a pair has changes in flight in an existing feature branch, perform a git merge between the existing feature branch and the feature branch derived from pcf_xyz_develop
  3. Upon story completion, a Pull Request should be issued for the feature branch in order to move the story changes back to pcf_xyz_develop
  4. All other active feature branches should immediately merge the latest changes from pcf_xyz_develop
    • It is always the responsibility of the pair to handle any merge conflicts that may arrive from a merge
  5. When possible, these stories should issue a new git repository for the specific project at which time, the above no longer applies for the specific project
    • All future stories will be worked upon in a feature branch of the new repository

Dealing with external changes

By isolating the sprint work in pcf_xyz_develop we are able to insulate ourselves from sporadic version increases. However, that does not mean we have to neglect the external changes. In fact, its the opposite.

  1. On a schedule of our choosing, pcf_xyz_develop will pull in changes from develop
  2. All other active feature branches should immediately merge the latest changes from pcf_xyz_develop
    • It is always the responsibility of the pair to handle any merge conflicts that may arrive from a merge
Contact us