Back To The Sources – Project Repositories and Branching Model

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.

Branching model

Our branching model is quite simple (adapted from the well-known Vincent Driessen’s branching model and which is now supported by various tools and used by many companies like Atlassian).

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”.

Repositories organization

Aiming security and backup purpose, we are using two repository kinds (owned by two distinct github organizations).

These are blessed and development repositories hosted respectively on exoplatform and exodev organizations.

Development repositories are forked from blessed repositories.

04-dev-repositories

Branches and repositories

Development repository

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.

Blessed repository

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.

Make the most out of eXo Platform 4

Register to the next webinar and get a complete overview of what you can do with eXo Platform 4. Reserve your seat now!

Be part of the discussion, share your comments

comments