Introduction
In this introduction, I would like to explain the reasons that pushed me to write this article. I already wrote an article about some best practices in solution development. And then I figured out that the section Configuration Management is a MUST could be a separate article.
I've been working with several teams on different projects, and I sometimes had the role of release management. The projects where the team did not respect the standards of creating branches and merging them using pull requests made the task really hard for me. It was because the team members were not convinced of the benefits of gitflow and the branching methods. They find it a useless process made just to annoy them.
Why should they create a separate branch for each feature/bug-fix/Hotfix? Why should they have a branch develop? Why all this headache when they can directly push on the master branch? It will create automatically two heads, they merge them, perform some tests, and everything is done !!
In this article, I will try to answer this kind of questions, and I hope it will help to bring a better understanding of the process.
Prerequisite
- Familiarity with configuration management.
- Familiarity with code management tools like git/azure devops / mercurial.
What is a Branch
Creating a branch means you will get the point of reference in the history of the commits in your repository, and then you will begin to perform updates starting from it.
Your work will progress independently from the other team member's source code. Here, it means that you are working on a separate branch. If you push it to the server, it will not affect the other members' work because it's evolving separately. And once you finish, you need to group your work with the other member's work. Here you need to do the merge.
The merge is done from your current branch (source branch) to the destination branch. Some conflicts may occur, and here you need to resolve them (in best cases with the member that wrote the conflicting code in the destination branch). The destination branch may vary according to the purpose of development.
Branches are not only created to perform a specific development apart, there are some "well known" branches that are made to consolidate the development done by the team.
Here comes the gitflow; in gitflow, there is a set of branches that will represent the status of the work at one stage of the development process.
What is Gitflow?
Gitflow is, first of all, a branching model but is also a flow that defines the relations between these branches and the process of merging between them. It means that when the development team members work on the same repository, they should respect some standards and rules before pushing and merging their codes. In other words, if one developer starts to work on the code, the base branch from which he will create his own branch will vary according to the nature of his development, scope, and purpose. It's also the same case for the destination branch. This will be detailed in the further sections.
I want to mention that gitflow is a process independent of the technology you use to manage the configuration. The following image (as defined by gitflow) summarizes everything.
![]()
figure 1
Source: https://git-flow.readthedocs.io/en/latest/presentation.html
Why do we use a branch develop?
When a repository is created, you initially have only the master branch. Now you can start working and pushing your code. You can do it directly on the master branch and use tags, but after delivering a release, you need to work again on the master branch. And here, your latest commit will not be stable since all the intermediate development of the team will be done on the master. Here comes the gitflow to separate the branches according to the phase.
The branch develop is a kind of "draft" branch. It will hold all the eventual instability and the continuous implementation during sprints and before performing the release. Let's take the example of a team starting a new project to develop an ERP. Let's suppose that in the first sprint, they should develop the login module, in the second one, the management of the sales, and in the third one the accounting module. After three sprints, the team should deliver a release that holds all these three features.
Here the branch develop (the yellow dots in Figure 1) should be created, and every team member should merge their work to this branch develop after finishing it. I would say that - in terms of environments - the branch develop corresponds to the development environment.
- Thus, the benefit of the branch develop is that it holds the convergence of all the different works of all the team members before delivering a release.
Why do we use a branch feature?
Every team member should merge their work into the branch develop before delivering the release. But from where?
If the developer is working on a new feature ( let's take the login feature in our ERP example), he needs to create a separate branch for it. Once he considers that the work is finished, he can start merging it to the branch develop. So the purpose is mainly the implementation of a new feature (as shown in the pink dots in Figure 1).
- Thus, the benefit of the branch feature is that during the development stage, the developer's work will not impact or be impacted by the development done by the other members until the merge.
Why do we use a branch release?
Once all the development of the features is done and merged into the develop branch, the development team should deliver a released version to the QA Team.
The QA will start working on the application, and the development team will continue coding the next project's features. But also, if a bug is found on the delivered release, the dev team should fix it. Here comes the importance of the release branch: If the developer implements a new feature, he will start working from the branch develop, as we mentioned in the previous section. But if he needs to fix a bug discovered by the QA team, he will start working from the release branch (the green dots in Figure 1), which will ensure a separation between the released version's code and the continuous development. If we redirect our thinking to the environment's point of view, I would say that the branch release corresponds to the state of the system in the staging environment.
I would mention a missing point in Figure 1; the developer should create a separate branch bug fix and then merge it to the release branch in the same way that he creates a feature branch and then merges it into the develop.
- Thus, the benefit of the release branch is that it saves the released version from the updates that could be made in the post-release development phase.
Where comes the Master in all these branches?
It can be called Master, Main, or default, according to the tool you use (the blue dots in Figure 1). Whatever it's called, the master branch is there at the beginning and is defined as the root branch of all the branches that you may create in the repository. But in gitflow, it represents the status of your solution in the production stage.
In the previous section, we talked about the branch release, and we said that it's made to save the released version from the continuous development done in the develop. In the same way, the Master branch is there to save the version that will be deployed in the production from the other intermediate releases.
After the validation of the release by the QA and all the fixes by the development team, the solution should be stable enough to be deployed in production. So it can be merged to the master and tagged.
A crucial point that should be considered is that in one level, the develop should contain the development made in the release and master. It SHOULD NOT be done very frequently to avoid any instability, and also, IT SHOULD NOT be done far apart in time to avoid a big gap between them. So the best thing to do is once the bug fixes on the release branch are done (or a hotfix in production), the branch release should be merged to the develop simultaneously when it's merged to master.
What if a bug is discovered during production
As you can notice, we parsed all the branches in Figure 1 except the red one, which is the hotfix. This branch is made to be updated if a bug in production is discovered.
In this case, the update is done in the hotfix branch should have the latest updates of the master branch, then once the development is finished, it should be merged to both the master branch to be deployed in production and also to the branch develop to be considered in the next releases.
Conclusion
The team members should be aware of code management processes and best practices. They should also perform code reviews through the pull request before merging. It may appear a task that complexifies the process, but its benefits on the project's stability and maintainability will be immediately seen.
Please feel free to suggest other points that can make the code management better!