GitFlow
Git-flow is a versionning methodology implemented by Vincent Driessen which adds very efficient branching to your project. In the case of this project, we work using our type of Git-Flow. On this page, we will explain our approach and the strategy of each branch for the concept of game development.
For the following parts, you will see that we used five different branches. These branches are:
- Features (can have several of them, work in progress)
- Develop (main branch, source code)
- Release (pre-production, number of the version)
- Master (Other main branch, playable)
- Hot-fix (Emergency branch, bug in playable version)
For more information about Git-Flow in general, you can go to the following website : Git-Flow cheatsheet
When we created the project using the Git-Flow methodology, two branches were made, and these branches are very related to each other. I want to talk about the Develop and Master branch. We will come back to the Master branch in more details in the part which corresponds to it.
The Develop branch is the foundation of the project and contains all the code and features of the current project. Except for those that are under development, of course (the Features branch). It is from this branch that most of the project will develop. On the one hand, it is from this branch that the developers will work by pushing the Develop to a new branch Features. On the other hand, it is also the branch from which the new versions of the game will be born, and lead to its release and updates.
As you can see, this is an indispensable branch for the good progress of our project. We will see in the other part how the other branches are organized in relation to the Develop one.
The Feature branches (because they can be more than one) gather all the branches whose development is in progress. As we saw in the previous part, they all come from the same base, the Develop branch.
In order to organize the project as much as possible and not to encroach on the work of one's colleagues, Feature branches are created. They are based on the tasks of the current sprint. They only deal with one aspect at a time. The end of the development of the feature involves a Pull Request and after validation, the closure of the branch.
Their implementation is simple. At first, just push from the Develop branch to create the feature of your choice. After the development, the content of the branch is pulled onto the Develop, bringing its package of novelty.
The Release branch is the new version branch of the project. Its role is to stick a tag with the version number on the progress of our video game.
The theory is quite simple: as soon as the progress of the project is sufficiently substantial (that is to say that the Develop branch brings a lot of good novelties), the team decides to migrate to this branch, bringing a version number.
The practice is just as simple, always from the Develop branch, just push the project on the Release branch and indicate the version number, a number higher than the previous one.
It's time to talk about the Master branch, an almost twin branch to the Develop one. It is important to note that this is the playable branch of the project, it has all the elements required for players to enjoy the game.
It is alsi important to note that the Master branch also has a version number. In fact, after performing all the pre-production tests on the Release branch, the content of this branch will be merged with the other two branches (Develop and Master). This will distribute the playable version and maintain the same state of the project on the development branch for future enhancements.
In conclusion, we have on the one hand the Master branch with the latest version ready to play, and on the other hand the same content (with the right to handle it) for developers.
The Hot-Fix branch is a very representative branch of our project. It shows our real investment for this project as well as our passion for the game. It represents our desire to make a game that guarantees the best gaming experience for all those who will play it.
This branch is completely related to the Master branch (the playable branch). Indeed, anytime players notice some bugs during a game, we will have to push the project on this branch to correct any bug. These bugs can be of different kinds, whether it is a real imbalance between classes (pushing other classes to never play or even advance abnormally in the adventure), or bugs that don't prevent the game from working, like bugs that we would not have seen in test (walls that we can cross, etc.)
Its implementation is very simple. Just push up to the last version in progress, a new branch called Hot-Fix. It is on this branch that we will work to solve all the problems encountered. Once the problems are solved, it is necessary to merge the result of the corrections with two different branches. If you follow me since the beginning of the explanation, you will understand that it is necessary to merge with the branch Master on the one hand (to free the players from the problems encountered in the game), but also with the branch Develop (for the continuation of the development, it is necessary to be able to continue without carrying the bugs on to the next version).
