Teamwork Without Confusion: Exploring Gita Branching Strategies

Introduction

Git has become the de facto industry standard for version control in software development. About what git is and how to get started, read my article about it first . Have you read? Great, let's move on! Whether we like it or not, the tool that Linus Tovalds created is not about to retire. Therefore, it makes sense to talk about how distributed teams work in a git and what branching strategy to choose for this. And this is not an idle question. Often in a situation where a new development team is being assembled that has not collaborated with each other, the branching strategy is one of the first things to decide. 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 are in general.

Are branching strategies necessary?

But they are needed, and how they are 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;
• stink into other branches he wants to;
• delete some branches;
• create new ones;
• and so is each of the team members in the unmanaged thread.

Therefore, below are three strategies. Go!

GitHub Flow Strategy

The branching strategy is, oddly enough, GitHub's preferred one :) It comes with a set of rules to follow:

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 the project from being built and deployed to 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 friendly name. Commit your code locally and regularly push your changes to the same branch to the remote repository.
3. Open a Pull-Request (what a pull-request is, you can read 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 you want to get feedback on the work done).
4. Once 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, 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 on the implementation begins. You need to constantly send commits to a remote server with the same name. When it comes to understanding that everything is ready, you need to create a pull request in the master branch. Then at least one, or better, two people should look at this code and click Approve. Usually, the team leader of the project and someone else should definitely look at it, and then you can already complete the pull request. GitHub Flow is also known for driving Continuous Delivery (CD) on the project. Because when changes come into the master branch, they should 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 already more serious. At least you can understand it from the picture above) 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: this branch should not be touched/pushed by anyone just for the sake of it. In this strategy, master displays the latest stable version that is used in production (that is, on a real server);
• development is the development branch. Potentially it can be unstable.

Development is carried out using three auxiliary temporary branches :

1. Feature branches - for developing new functionality.
2. Release branches - to prepare the release of a new version of the project.
3. Branch hotfix (hotfix branches) - a quick solution to a defect that real users have already found on a real server.

Feature branches

Feature branches are created by developers for new functionality. They should always be based on the development branch. After completing work on 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 branch feature at the same time. 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 are prepared in the development branch, you can prepare for the release of a new version of the product. The release branch will help us with this. which is created based on the development branch. During the work with the release branch, you need to find and fix all the defects. Any new changes that are required to stabilize the release branch should also be merged back into development. This is done in order to stabilize the development 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 is Tag 1.0 is just a label that indicates version 1.0 of the project. And the last one is a branch hotfix.

Hotfix branches

Branch hotfixes are also meant to release a new version to master. Only difference is that this release is not planned. There are situations when defects reach the release and are already found in the work. For example, iOS: as soon as a new version is released, you immediately get a bunch of updates with fixes for defects that are discovered after the release. In this regard, you need 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 the moments when it is necessary to fix a defect on a real server (as we say, “on production”: again a tracing paper from the English word production). The hotfix branch should be created from the master branch, as it represents the state that is running in the prod. Once the defect solution is ready, merged into master, 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 where all changes will be merged.
2. Fork repository (this is a copy of the original repository owned by another developer who wants to make changes to the original).

While it sounds kind of weird, right? For those who have already dealt with open-source development, this approach is already familiar. This strategy has the following advantage: development can be carried out in a forked repository and 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 smerdzhit them. This is convenient for both the owner of the original repository and the developer who wants to participate in the creation of some kind of product. For example, you can propose changes to the Linux kernel . If Linus decides that they make sense, the changes will be added (!!!).

The Forking Workflow Example

The Forking Flow is applied on GitHub at the moment when there is some kind of library that you want to use. It has a defect that prevents it from being fully used. Let's say you've delved into the problem enough 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 some kind of repository, for example, the core Spring Framework , 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. It is clear that there is no single answer for everyone. Everything depends on the situation. However, there are a few guidelines that can help with this:

1. It is better to choose the simplest strategy first. Move on to more complex strategies only when necessary.
2. Consider strategies that have as few branch types as possible for developers.
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 say about the branching strategy in the git. Thank you for your attention :) Subscribe to my github account , I often post my work there in different 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 do I make changes to someone else's project
• GitHub: About Pull Requests
• Continuous Integration, Delivery, and Deployment Differentiated
• Git Basics: Working with Labels
• Habr: Successful branching model for Git