Gitflow auxiliary branches

After you have installed gitflow and created your gitflow repository, you can start developing the project on the branch. However, this process is not as easy as it seems: projects may have multiple versions and even more bugs. To deal with them, we need to include auxiliary branches in our gitflow structure for new project variants, for working out errors, and for releasing new versions.

Auxiliary branches

During work, you can create so-called feature branches based on develop. There can be an unlimited number of them. These branches are used to develop new features that should appear in current or future releases. Since they are auxiliary, they have a limited lifespan. When a feature is done, the corresponding branch should be merged into the develop branch, and then it will be automatically removed. In the simplest case, if you don't need to develop any additional features, you don't need such branches at all. But if you decide to add new functionality to your project, it will be convenient to first write and test it separately, without spoiling the code already created on the develop branch.

Release branches are used to prepare for the release of new versions of a project. They allow you to make final edits. They are created when a development project on a branch is almost or completely ready. You will normally use them if you are going to have several versions of the whole project and want to release them one by one.

Hotfix branches are similar to release branches in that they are created and used when working on new versions. But the difference is that they are only needed to immediately correct unwanted behavior, i.e., a bug in the production version. The advantage is that your team can keep working on the develop branch while one of you fixes the version bugs. You will need them if you find some errors in your code during development.

Working process

The working process in Gitflow follows approximately the algorithm below:

1. the repository is initialized;

2. the work on the project begins on the develop branch;

3. If you need to try a new thing, a feature branch is created;

4. when a new feature is ready, the feature branch is merged into develop and removed;

5. If everyone is happy with the current version, a release branch is created, where bugs will be fixed;

6. after fixing all the errors, the release version is merged to main.

Commands

Commands we need are displayed in the picture:

Based on this template, the main commands are created:git flow <branch> <action> <branch_name>. To create a new branch, for example, feature, you need to choose start action:

$ git flow feature start new_feature

You will have a new feature branch based on the develop branch, and you will automatically switch to it. And when you're done with it, use the finish action:

$ git flow feature finish new_feature

So you will immediately do three actions: merge the feature with the develop branch, delete the original feature branch and stay on the develop branch to continue working. Don't forget to commit your changes before finishing! The hotfix and release branches are created and completed in the same way.

To upload the results of your work to a remote server, for example, to GitHub, you need to select the publish action.
The command for publishing, for example, a release will look like this:

$ git flow release publish my_release

And in order to download, for example, a fix, you need to select the pull action:

$ git flow hotfix pull new_version

Tags and tracks

The number of your update or fix can be written directly into the name like git flow hotfix start version 1.0 , or you can use the command git tag -a 1.0. If you make any changes to the tags, then do not forget to send them to the server later, too by git push --tags.

In addition to tagging, it can also be convenient to track a remote release or feature in the origin repository using:

$ git flow feature track new_feature

Conclusion

The gitflow model can be very helpful in the development of various projects. It allows you to see the picture of the problem as a whole and structure the work on its solution. Following the Gitflow encourages the team to have a shared understanding of the branching and merging processes at work in the project. We have analyzed the basic commands and structure of working with gitflow. Hopefully, you can now follow this model as you start developing big IT projects!