As described previously, nowadays all our projects are using Git as Version Control System. Git is a powerful tool to manage sources but as it brings many more features than git it requires to define more conventions. Let’s see how we defined them for eXo projects.
Working with sources
While in Subversion your rules may have been to organize your code in the common trunk/tags/branches pattern with Git and its distributed nature you have a high interest to define various workflows to work in with your sources at a personal, team and company levels. Without it, it may be very challenging to find where are the latest sources.
In our model, we have four kinds of branch:
- master : Master branch is used as main branch where long term developments are done.
- feature/xxx : Feature branches are dedicated branch for one big feature (lot of commits), “xxx” is the feature name.
- stable/xxx : Stable branch are used to perform releases and write / accept fix. “xxx” is the stable version name (e.g 1.0.x).
- fix/yyy/xxx : Fix branch is dedicated to integrate bugfix on stable branch “yyy”. When the branch is ready, a pull request will be done. “xxx” could be for example “PROJECT-12345” and “yyy” could be “1.0.x”.
Aiming security and backup purpose, we are using two repository kinds (owned by two distinct github organizations).
Development repositories are forked from blessed repositories.
Branches and repositories
This repository is the developers repository. The main development branch is master branch. Depending the contribution kind (one shot contribution or feature contribution), the developer can use a dedicated feature branch if needed.
The most of development activity will be done in this repository by a lot of contributors :
- maintainers : To develop fix on some stable version. These developments are done in dedicated fix branches (more details below).
- all development teams : To do one shot contribution and handle feature branch life cycle.
In this repository you can find stable branches and release tags. There is master branch also automatically synchronized from the one in the development repository clone (as backup).
Only some people are able to write on this repository :
- maintainers : To integrate pull request on stable branches.
- release manager : To perform release operations on stable (supported) branches.
- keepers : Repository keepers are Project Leader, Team Leader and Technical Leader. They are able to pull changes from dev to blessed when the master is stable enough and they can process releases on master branch for non supported versions of products (alpha, beta, RCs, …)
You’ll find more details about how we manage these different branches in this documentation. All comments and ideas to improve them are welcome.