Git_Branching_Strategy

---

title: Git_Branching_Strategy
updated_on: Wed Feb 09 22:00:34 ~~0500 2011\

\
}
\
h1. 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.
\
h2. 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
    [[General\_Development\_Process\#What-is-done|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’.