👅 👨‍💼 🧔🏾 Please stop recommending git flow 🐐 🧝🏿 👳🏿

Note perev. : A new article criticizing Git Flow, which many have loved, has received so much attention that even the original author of the model updated the publication 10 years ago, updating her view on its use today. We publish a translation of both the criticism itself and the official reaction.

Git-flow is a branching and merging methodology that was greatly popularized in a 2010 note entitled “A Successful Git branching model” (translated into a hub as “A successful branching model for Git ” - approx. Transl.) .

Over the past ten years, countless teams have fallen victim to this famous name and have appeared - I am not afraid of the word - frankly fool. In his note, the author claims that they have successfully implemented this model in projects, but intentionally does not disclose the details of the projects that led to this “success” .

And this is the main mistake of those who believe this publication. It is a well-known fact that not all strategies work in all situations, with all people, in all contexts. And I argue that the same logic applies to this branching model.

You can end here, right? Well, not quite. Surely some of you were skeptical of my line of reasoning, so let's dig a little deeper and try to understand why the Git-flow branch model should be fried over low heat .

Git-flow is initially complicated and confusing

The Git-flow model is complicated even if you forget about microservices and continuous delivery (CD) for a minute. Take a look at this scheme and take a chance to say that it is intuitive:

( source )

So, we have feature branches, release branches, master , develop , patch branches (hotfix) and git tags. All these elements must be monitored, kept in mind, and taken into account during assembly and release.

In addition, you need to constantlyfocus on what the branch is and what it is for. The mental model that is required to implement this approach carries a high cognitive load. I have been using git for 10 years, but still I'm not sure that I can keep in mind all the nuances of what is happening.

Git-flow breaks the rule of "short-lived" branches

In git, the number of merge conflicts in a branch grows in proportion to the number of people committing to that branch. In the case of Git-flow, this number grows even faster, because there are three other branches (with different lifespan) that merge into develop: the branches of functionality, releases and fixes. Thus, the potential number of merge conflicts is now at least three times higher.

No thanks!

I am not inclined to say that worries about merge conflicts are a good reason to abandon a branching strategy like Git-flow, but the potential complexity associated with all of these branches cannot be ignored. Such an approach would be suitable for an organization with a low frequency of commits, but it is not suitable for any dynamically developing company or startup.

With git-flow you have to forget about rebases

I admit that relocation is a multifaceted issue, but it is important for the purposes of my narrative. Git-flow supporters will have to abandon relocation: it happens along with the merger, as a result of which the two branches merge. And given the visibility of Git-flow problems, you will need a way to visually track branches. In order not to do this, you will have to forget about rebase forever.

Git-flow greatly complicates continuous delivery

Continuous delivery is a practice in which developers release updates directly to production (in fact, by merging with the master) in automatic mode. Now look at the mess that is going on in Git-flow, and explain to me how you are going to carry out continuous delivery of all this ?

The whole branching model is based on a predictable, long-term release cycle for new versions, not the release of new code every few minutes or hours. It’s too difficult to implement, not to mention the practice adopted in the CD to roll fixes “in place”, while Git-flow considers corrections as a separate entity that must be carefully stored, controlled, keeping it separate from the rest of the work.

Git-flow cannot work with multiple repositories

With the advent of microservices, the idea of microrepositories began to gain popularity (“They are orthogonal to each other,” the prompter shouts to me). In it, individual teams control their repositories and workflows, and also keep track of who publishes the code in their repository and how their workflows function.

Have you ever tried to use a complex branching model like Git-flow when several teams work together? Did you manage to achieve coordination of their actions? I doubt it. Very soon, the system turns into a manifest of various revisions of different repositories, and the only ones who know where everything lies are the people who write YAML files to update the manifest. If you do not observe proper caution, then the question "What do we have in production?" becomes existential.

Git-flow is also not suited for working with a single repository.

If microrepositories are not suitable due to the complexity of coordinating releases, why not implement a single global branching process that all microservice teams will use for releases?

Alas, it will last only a few seconds - exactly as long as the team needs to say: “This must be released right now” (although the rest of the teams are not at all ready to release their products). In the case when the teams work independently of each other, microservices are also deployed independently, it is impossible to link the workflow to a centralized branching model organized in a monorep.

To whom is Git-flow suitable (and not suitable)?

If your company adheres to a monthly or quarterly cycle of software release, and the team works on several releases in parallel, then Git-flow may be a good choice. For a startup, website or web application with many releases every day, Git-flow is not suitable. If the development team is small (less than 10 people), then Git-flow contributes too many ceremonies and unnecessary movements to its work.

On the other hand, if the team has 20+ people working on parallel releases, then Gitflow provides sufficient structure to help avoid confusion.

Okay, Git-flow isn’t suitable for my team. What should we use?

I can not answer this question. Each branching model is appropriate for the respective teams, cultures and conditions. Supporters of the CD fit the model that simplifies the process. Someone loves to develop on the basis of trunk'ov ( trunk-based development ) and a switch function (The flags feature) . However, these approaches to hell scare me with the complexity of testing.

The main idea is to discuss this issue in detail with your team. Ask her the following questions:

What problems does this branching model help us solve?
What problems will she create?
What development approaches does it stimulate?
Do we want this?

Any branching model is ultimately designed to make it easier for developers to work together on software, so it must take into account the needs of specific people who will use it. You should not choose a certain model, based only on the fact that someone wrote her an ode on the Internet.

In conclusion, I want to say that I originally intended to use the stable expression “considered harmful” in the title, so familiar for publications of this kind. However, a google search revealed that someone had already used it for their article on the dangers of Gitflow . I recommend reading it.

Bonus Reply nvie (Vincent Driessen)

The day after this publication, the author of the original “ A Successful Git branching model ” (Vincent Driessen), referenced by George Stocker, posted the answer:

(5 2020)

2010 — 10 — , Git. 10 Git-flow ( , ) , — , , .

10 Git , , Git, - — , . , - CD, .

, , . , , ( GitHub flow) , Git-flow .

, Git-flow , (Git-flow 10 ). .

, . , !

PS More opinions on this topic, of course, can be found on Hacker News and Reddit .

Please stop recommending git flow