112 lines
7 KiB
YAML
112 lines
7 KiB
YAML
uuid:
|
|
- value: dec2b9a9-a942-420c-ad1c-a41ab979ba6b
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:18+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'Why do people still use Git Flow?'
|
|
created:
|
|
- value: '2024-02-25T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:18+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2024/02/25/why-do-people-still-use-git-flow
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p><a href="/presentations/git-flow">The first conference talk I gave</a> was at DrupalCamp London 2014.</p>
|
|
|
|
<p>The talk was about Git Flow - a popular branching scheme I was using to manage a project, where there are different branches for development and production versions of the software and separate branches for features, releases and hotfixes.</p>
|
|
|
|
<p>It's been a standard approach as I've worked on different projects and teams, usually with pull or merge requests and code reviews.</p>
|
|
|
|
<p>But why do people still use it?</p>
|
|
|
|
<p>I was conducting technical interviews recently and every candidate explained how they used Git Flow or something inspired by it, and GitHub and GitLab have their own simplified versions.</p>
|
|
|
|
<p>Vincent Driessen wrote the original Git Flow blog post in January 2010, though he updated it in March 2020 to add this note of reflection:</p>
|
|
|
|
<blockquote>
|
|
<p>This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.</p>
|
|
|
|
<p>During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.</p>
|
|
|
|
<p>This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.</p>
|
|
|
|
<p>If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.</p>
|
|
|
|
<p>To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.</p>
|
|
</blockquote>
|
|
|
|
<p>Since adopting trunk-based development and continuous integration and delivery, I've worked faster and avoided merge conflicts, which wasn't the case before, even when I was the only one working on a codebase.</p>
|
|
|
|
<p>It's a simpler workflow.</p>
|
|
|
|
<p>I don't need to think about whether this branch is a feature or a hotfix, and I've rarely seen release and hotfix branches used as described in the original blog post.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>Do what works best for you and your team, but don't adopt something because it's the "standard" approach.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p><a href="http://default/presentations/git-flow">The first conference talk I gave</a> was at DrupalCamp London 2014.</p>
|
|
|
|
<p>The talk was about Git Flow - a popular branching scheme I was using to manage a project, where there are different branches for development and production versions of the software and separate branches for features, releases and hotfixes.</p>
|
|
|
|
<p>It's been a standard approach as I've worked on different projects and teams, usually with pull or merge requests and code reviews.</p>
|
|
|
|
<p>But why do people still use it?</p>
|
|
|
|
<p>I was conducting technical interviews recently and every candidate explained how they used Git Flow or something inspired by it, and GitHub and GitLab have their own simplified versions.</p>
|
|
|
|
<p>Vincent Driessen wrote the original Git Flow blog post in January 2010, though he updated it in March 2020 to add this note of reflection:</p>
|
|
|
|
<blockquote>
|
|
<p>This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.</p>
|
|
|
|
<p>During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.</p>
|
|
|
|
<p>This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.</p>
|
|
|
|
<p>If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.</p>
|
|
|
|
<p>To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.</p>
|
|
</blockquote>
|
|
|
|
<p>Since adopting trunk-based development and continuous integration and delivery, I've worked faster and avoided merge conflicts, which wasn't the case before, even when I was the only one working on a codebase.</p>
|
|
|
|
<p>It's a simpler workflow.</p>
|
|
|
|
<p>I don't need to think about whether this branch is a feature or a hotfix, and I've rarely seen release and hotfix branches used as described in the original blog post.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>Do what works best for you and your team, but don't adopt something because it's the "standard" approach.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|