Do you have a large project in hand and you don’t know how to coordinate your team? To this end, there are different remote repositories which allow coordinating the whole team. In addition, once the project has been launched, we may want to introduce changes which weren’t previously considered or to include new functions. For these reasons, it is advisable to implement a central working model which, in our case, happens to be the Git Branching Model

What if we implemented descentralised model? We could find that new functions contain errors or that different programmers have overlapped each other’s work. Moreover, if users are constantly spotting those errors, company and product image and reputation may result damaged.

To prevent this, eHidra implemented this working method in which new functions and errors spotted after launch are constantly checked. How? By using a remote repository such as GitHub.

Git Branching Model: Working environments

To make all those checks possible, different working environment are needed. We organise it as follows:

  • Development: this environment is only accessible for developers. Therefore, this will be the first one to check when testing new features.
  • Staging: after being successfully tested in the previous stage, new features are tested again in this environment just in case some error wasn’t spotted. We have to bear in mind that new features will be accessible for users right after this stage so we should undergo as many tests as possible. Some users will be given access to this environment to do as many test as required.
  • Live: this is the final environment. That is to say, this is the space any user can access. Only those features which have been successfully tested in the development and staging environments are included.
  • Branchs-1


    We can keep our project code in remote repositories and make it accessible for the rest of the team. In this way, it is possible to work simultaneously. GitHub allow creating the so-called branches in order to avoid overlaps when working. We will have two main branches:

  • Develop
  • Master
  • In the first one, there will be those changes to introduce, while in the second one there will be the source code ready to run.

    A clear distinction according to issue should be made between the three types of secondary branches.

  • If we are including a new function, we will use a feature branche. Once its correct functioning is checked, this kind of branches must be merged into the develop branch and this one in turn into the development environment.
  • If we are fixing a detected error, then release branches are the ones to use. As in the previous case, they must be emerged into the development environment after the developer has checked that the error has been fixed.
  • If it is a serious error which must be immediately fixed, we must make use of Hotfix Branches. These would be the only ones directly emerged into the main master branch so that they can be immediately accessible by users.
  • Programmers will create secondary branches in the development branch for each error in the remote repository to be fixed. In this way, each branch will contain all information in the develop branch, as well as the code added by the programmer without affecting other team members.