Teamwork without Confusion: Understanding Branching Strategies in Git

Introduction

Git has become the de facto industry standard for version control in software creation. To learn about what git is and how to get started, first read my article about it. Have you read it? Great, let's move on! Like it or not, the instrument that Linus Towalds created is not going to retire. Therefore, it makes sense to talk about how distributed teams work in git and what branching strategy to choose for this. And this is not an idle question at all. Often, in a situation where a new team of developers who have not collaborated with each other is assembled, branching strategy is one of the first things that needs to be decided. And there will be people who will foam at the mouth to prove that one strategy is better than another. Therefore, I want to convey to you information about what they generally are.

Are branching strategies necessary?

But they are needed, and they are still needed. Because if you don’t agree on something in the team, it turns out that everyone will do what they want:

• work in the branch in which he wants;
• merge into other branches he wants;
• delete some branches;
• create new ones;
• and so on—each of the team members is in an uncontrolled flow.

Therefore, below are three strategies. Go!

GitHub Flow strategy

The branching strategy, no matter how strange it may be, is preferred in GitHub :) Attached to it is a set of rules that need to be followed:

1. The code in the master branch must be unbroken and ready to be deployed at any time (that is, you cannot put code there that will prevent you from building the project and deploying it on the server).
2. When you plan to work on new functionality, you need to create a new branch (feature branch) based on the master branch and give it a meaningful name. Commit your code locally and regularly push your changes to the same branch in a remote repository.
3. Open a Pull-Request (you can read what a pull-request is here ) when there is a clear feeling that the work is ready and can be merged into the master branch (or if you are not sure, but want to get feedback on the work done).
4. After a new feature in a pull request has been approved, it can be merged into the master branch.
5. When changes are merged into the master branch, they need to be deployed to the server immediately.

According to GitHub Flow, it turns out that before you start working on something new, be it a fix or a new feature, you need to create a new branch based on master and give it a suitable name. Next, work begins on implementation. You need to constantly push commits to a remote server with the same name. When you understand that everything is ready, you need to create a pull request in the master branch. Then at least one, or better yet, two people should look at this code and click Approve. Usually, the team lead of the project and someone else must look at it, and then you can complete the pull request. GitHub Flow is also known for driving Continuous Delivery (CD) on a project. Because when changes are made to the master branch, they must immediately be deployed to the server.

GitFlow strategy

The previous strategy (GitHub Flow) was essentially not very complex. There are two types of branches: master and feature branches. But GitFlow is more serious. At least from the picture above you can understand this) So, how does this strategy work? In general, GitFlow consists of two permanent branches and several types of temporary branches (In the context of GitHub Flow, the master branch is permanent and the others are temporary). Permanent branches:

• master: no one should touch this branch or push anything there. In this strategy, master displays the latest stable version that is used in production (that is, on the real server);
• development is the branch for development. It could potentially be unstable.

Development is carried out using three auxiliary temporary branches :

1. Feature branches - for developing new functionality.
2. Release branches - to prepare for the release of a new version of the project.
3. Hotfix branches are a quick solution to a defect that was already found by real users on a real server.

Feature branches

Feature branches are created by developers for new functionality. They should always be created based on the development branch. After completing work on the new functionality, you need to create a pull request in the development branch. It is clear that in large teams there can be more than one feature branch at a time. Once again, pay attention to the picture at the beginning of the description of the GitFlow strategy.

Release branches

When the required number of new features have been prepared in the development branch, you can prepare to release a new version of the product. The release branch will help us with this. which is created based on the development branch. While working with the release branch, you need to find and fix all the defects. Any new changes that are required to stabilize the release branch must also be merged back into development. This is done in order to stabilize and develop the branch. When the testers say that the branch is stable enough for a new release, it is merged into the master branch. Next, a tag is created on this commit (tag: you can read more about it here ), which is assigned a version number. As an example, you can look at the picture at the beginning of the strategy. So, there Tag 1.0 is just a label that indicates version 1.0 of the project. And the last thing is a branch hotfix.

Hotfix branches

Hotfix branches are also intended for the release of a new version in master. The only difference is that this release is not planned. There are situations when defects reach release and are already discovered in production. For example, iOS: as soon as they release a new version, you immediately get a bunch of updates with fixes for defects that are discovered after the release. In this regard, it is necessary to quickly fix this defect and release a new version. In our picture this corresponds to version 1.0.1. The idea is that work on new functionality may not stop at moments when you need to fix a defect on a real server (as we say, “in production”: again, a copy of the English word production). The hotfix branch should be created from the master branch, since it represents the state that works in production. As soon as the solution to the defect is ready, it is merged into master, and a new label is created. Just like preparing a release branch, a hotfix branch should merge its solution into the development branch.

The Forking Workflow strategy

As part of the Forking Workflow strategy, development is carried out in such a way that there are two repositories:

1. The original repository into which all changes will be merged.
2. A fork repository (this is a copy of the original repository in the possession of another developer who wants to make changes to the original).

Sounds a little strange so far, right? For those who have already encountered open-source development, this approach is already familiar. This strategy provides the following advantage: development can be carried out in a fork repository without granting rights to joint development in the original one. Of course, the owner of the original repository has the right to reject the proposed changes. Or agree and kill them. This is convenient for both the owner of the original repository and the developer who wants to participate in the creation of some product. For example, you can propose changes to the Linux kernel . If Linus decides they make sense, the changes will be added (!!!).

The Forking Workflow Example

The Forking Flow is used on GitHub when there is some library that you want to use. It has a defect that prevents it from being used fully. Let's say you've delved enough into the problem and know the solution. Using The Forking Workflow strategy, you can solve this problem without granting rights to work in the original library repository. To get started, you need to select a repository, for example, the Spring Framework core . Find the Fork button in the upper right corner and click it: This will take some time, after which a copy of this original repository will appear in your personal account, which will indicate that it is a fork: Then you can work with this repository as usual, add changes to the master branch and when everything is ready, create a Pull-Request to the original repository. To do this, click the New Pull request button :

Which strategy to choose

Git is a flexible and powerful tool that allows you to work using a wide range of processes and strategies. But the greater the choice, the more difficult it is to decide which strategy to choose now. Clearly, there is no one-size-fits-all answer. It all depends on the situation. However, there are a few recommendations that can help with this:

1. It is better to choose the simplest strategy first. Move to more complex strategies only when necessary.
2. Consider strategies that have as few types of developer branches as possible.
3. Look at the pros and cons of different strategies and, in accordance with the project, choose the right one.

That's all I wanted to tell you about the branching strategy in git. Thank you for your attention :) Subscribe to my GitHub account , I often post my work there in various technologies and tools that I use in my work

useful links

• GitHub flow: the best way to use Git and GitHub
• Pull requests on GitHub or How can I make changes to someone else's project
• GitHub: About Pull-Requests
• Continuous Integration, Delivery, and Deployment Differentiated
• Git Basics: Working with Tags
• Habr: Successful branching model for Git