This meta-data will be removed once the page ideas have matured sufficiently or when the whole page is dumped.
|STATUS:||Request for comments|
Why now? Moving the code base to a distributed version control system with cheap branching allows us to use this feature to clearly group commits based upon features and targeted releases. A model is also necessary to effectively implement a continuous integration system. CI requires program friendly branch names and purposes to minimize changes to the CI server's configurations.
To be decided:
- What is the relationship of https://github.com/Bcfg2/bcfg2 and git://git.mcs.anl.gov/bcfg2.git ?
- Best practices for submitting patches (that should go in another document, but may affect this document)
2012.02.05 - RaulCuza? - Updated to reflect opinions to reflect feedback on bcfg-dev mailing list. master is now the primary development branch for the next release. maint, as described on the list will exist as a release/* branch. The git-flow makes the creation and merging of work done on these branches quite simple. I will demonstrate this by adding use cases at the end of this document.
Branching Model for Bcfg2 Development
The purpose of this model is facilitate the development of Bcfg2 by a disperse group of contributors at all times of its release cycle.
Vincent Driessen's A successful Git branching model was very influential in the creation of this model. Mr. Driessen is also the author of git-flow, a collection of Git extensions to provide high-level repository operations for his branching model.
This section should give those knowledgeable about Git all they need to know about using the model. If necessary more details will be provided in additional sections.
Reserved Branches and Branch Names
|Branch Name or Pattern||Description|
|master||HEAD on this branch represents the latest delivered development changes for the next release. While repository administrators will do there best to prevent it, HEAD may be broken on this branch. When that happens, the developers and repository administrators responsible for the commits that broke HEAD will make a reasonable effort to get it working again. This is a permanent branch.|
|production||Production ready states of the code. This branch uses release tags. Code on this branch will have passed tests developed by the Bcfg2 community (e.g. those on a CI server, when it is running). One can reasonably assume that HEAD on this branch is not broken.|
|release/*||Planned release branch, where * is the to be released version number.|
|hotfix/*||Unplanned release branch, where * is the to be released version number. Commits to this branch are limited to resolving the critical tickets that have to be released quickly.|
|feature branches||Feature branches can have any name other than master, develop, release-*, or hotfix-*. For the most part, these will live in an individual developer's repo only.|
The official repo has two permanent branches, master and production. The production will be a branch of convenience that will be easily maintained by the git-flow tool. All the information in it will exist as tags of master. The master branch will contain work for the next release. production will be subset of commits of master except for when a release is committed, then they will be identical.
The supporting branches are used for a limited time and then deleted when work on them is completed. There are supporting branch types:
- Feature branches
- Release branches
- Hotfix branches
These branches are optional and may not be used. As the number of maintainers is small and the release schedule of Bcfg2 is not hectic, most planned work can happen on individual developers' copies of bcfg2.git and then committed to master. Since git-flow supports these branches, making the complexity of their use simple, they are listed here in case they are needed.
This section, when written will contain use cases describing the steps for common bcfg2.git workflows.