-
Notifications
You must be signed in to change notification settings - Fork 0
Git_Branching_Strategy
{{toc}}
The intent of this document is the definitive source for our project branching strategy (or strategery, if you prefer). If there are changes in the future, this is where they will be documented.
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.
- 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 [[GeneralDevelopmentProcess#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.
- 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’.
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’.