Git_Branching_Strategy

Git Branching Strategy

The intent of this document is the definitive source for our project branching strategy . If there are changes in the future, this is where they will be documented.

Goals

What problems are we trying to solve or improve?

• Improve release management.
  • We want to be able to regularly cut releases that are reasonably expected to not be outright broken.
    • It should be as easy as possible to generate a new release on demand without having to worry about in-process features.
    • A release happens on a regular schedule, not when all features are complete, so incomplete features need to be easily excluded.
  • Support is needed for multiple people to work on the same feature before that feature is included as part of a formal release.
    • It is common that feature development will be spread across multiple team members .
    • We have a large team, and many times, part of a feature will be done by one developer, and needed by another to do their task - even though if they both finish, the feature may not be considered ‘done’ or ready to go in a release.
    • This makes it easier to track tasks like making sure there are proper rpm/dep updates, puppet config changes, and integration level testing with each given piece of functionality rather than treating them as catchall tasks that happen one time at the end of the sprint is done.
    • The business owners need to have an opportunity to say ‘this isn’t what I was expecting’ without impacting the team’s ability to produce a release.
• There should be consistent movement on the master branch to show the community that the project is under active development.

Current strategy

• All development happens in ‘next’ branch, developers never touch ‘master’.
• At the developer’s discretion, if they are working on a feature/story that is more involved (perhaps requires new packages, or is disruptive in some way, but other developers need to be able to get hold of the changes to work on their own tasks), any developer can create a public topic branch. Once this is ‘done’ (see what is done, these changes can be applied to next and pushed for expected inclusion in a release.
• At the end of each sprint, ‘next’ is merged into master by an ‘integrator’, tagged and we push a release to the yum repo.
• We may optionally create a release branch if we plan to maintain a release with bugfixes, but this is likely a future step.

Reasons for choosing this strategy

• Keeps master as the latest stable release, so if a new user clones it, they (theoretically) get something that works.
• Allows next to be relatively stable so it can be tested by QE for deciding what goes into a release (or what needs to be fixed first).
• Maintains a conceptual separation between ‘unstable/active development’ and ‘release quality’.

Why not Master as next?

We may reconsider this in the future, but at this point, it is too invasive for minimal gain, and there is some benefit to having a bit of formality around the process of ‘move this code from development to a release’.