“I am Marc Rosell, student of the Bachelor’s Degree in Video Games by UPC at CITM. This content is generated for the second year’s subject Project 2, under supervision of lecturer Marc Garrigó.”
Branching methods in projects help teams to work in parallel and to solve any problem or implement features in a simpler way, so that, there are policies to maintain control over all of them. Branching Policies are a set of rules created to help teams protect their branches of development. These policies enforce team's code quality and management.
To see the benefits of using Branching Policies, we will take a deeper look to two different ways of working with branches. The first one being a light branch policy, the Trunk-Based Development, and the second one with a much more strict policies, that is used by companies, the Feature Branching Development.
On one hand, the Trunk-Based Development is very similar to the one used in previous subjects, but using 2 branches. One branch is where the entire team works in the development of the features and separately has the branch for releases. Using this structure, when someone checks-in with wrong code it must be fixed in order to continue working (the entire team must wait for a fix). Now a days, this policy is outdated by the Feature Branching Development.
There are two types of Trunk-Based Development:
In this method, there are usually a small amout of programmers, each one commiting straight into the trunk or master. All the implementations must pass a pre-integration step, running the build first.
This method is best done with short-lived feature branches, for example: one person working for a maximum of two days. Then should pass a Pull-Request style code-review, before merging into the trunk.
On the other hand there is the Feature Branching Development, in which all the features and implementations are made external to the main branch and only integrated when they are completed, so the problem of waiting for the errors to be solved on the Trunk-Based Development is unexistant. In spite there are other inconveniences. For example, as the feature branches are used for a larger amout of time, if it isn't up to date, it could end up giving problems when merging with the main branch.
Gitflow is a branch policy for the Feature Branching Development:
This policy arises from the needs of organising a team of people to work in a same project and standards that may not have clear instructions on how to act in every situation that may come up, making it almost impossibl to work. So that, this set of rules, protect the main branches, making the administrator the only who can manipulate it, preventing possible repository damages. The memebers of the team can pull request and merge the branches on which they work (feature to develop), but in terms of develop, release, hotfixes and master branches the administrator is the only one who with permission to allow modifications to the main branches. Therefore, there might be more than one administrator. A nice method would be:
- Lead Programmer managing develop and hotfixes branches.
- QA Lead managing releases and master branches.
This will lead to a better QA testing using the Gitflow policies.
The other memebers of the team interact with these main branches by branching off from develop and creating their feature branch, in which they implement it and, after passing all needed verifications, merge it back to the develop branch creating a pull request.
The QA testing is done in the release branch, fixing it in this same branch and then merging back the branch into the develop and master branch. If it's found after its release then it would imply the creation of a hotfix branch.
Github, when the branches have been created, allows to add rules to the branches, for a better working of it and the team. For example, the verification that has to pass to complete a pull request, mentioned earlier.
To add these rules go to your repository then: Settings>Branches>Add Rule
The generic structure is:
We can distiguish the next branches:
In the Gitflow structure, these two branches are parallel and infinite, since their creation at the beginning of the project until its end. The master branch is only updated with the main stable versions of the project.
The feature branches are where the developers work on their own respective fields and tasks to develop different parts of the release in which the whole team is working. It is needed for these branches to keep updated with all the progress done in the develop branch, to avoid problems while merging.
- Branch off from: develop branch
- Merge back into: develop branch
Since all the features developed are in the develop branch, the release branch will serve as a support branch for the upcoming release. In this branch is where the QA testing is done. The issues are reported and are solved in this same branch. When the bugs are fixed, it is needed to merge back to the develop branch. Once it's all tested, almost everything fixed and confirmed to release, the metadata of the project as the version, is prepared. Then the branch merges with the master branch for the release launch into the master branch.
- Branch off from: develop branch
- Merge back into: develop and master branches
Hotfix branches are like release branches, to prepare a new release,yet unplanned. Is is created when a critical bug in a production release has been detected and must be immediately solved. One member can work on the problem while the rest keep working on their feature branches. Once the bug is solved, the tag must be changed, and it must merge into master and develop branches.
- Branch off from: master branch
- Merge back into: develop and master branches
Applications like AppVeyor, Travis CI, Jenkins, GitLab and others are made to help in the QA process. When connected with Github, their servers generate a build version of the project (need to be adjusted by the user). If it is configured to create the builds only when the commits are made in the release, master and hotfix branches, the QA testers don't need to do it by themselves and can start directly to test it.
- In groups, structure your project using the Gitflow structure.
A Successful Git Branching Model
Administrating a Repository - Protected Branches