---
title: '3 Git Workflows Every Developer Should Know (And When to Use Each)'
source: 'https://youtube.com/watch?v=GQQqf-C2ha4'
video_id: 'GQQqf-C2ha4'
date: 2026-08-19
duration_sec: 1892
channel: 'TechWorld with Nana'
---

# 3 Git Workflows Every Developer Should Know (And When to Use Each)

> Source: [3 Git Workflows Every Developer Should Know (And When to Use Each)](https://youtube.com/watch?v=GQQqf-C2ha4)

## Summary

This video provides a comprehensive overview of the three main Git workflows—Git Flow, GitHub Flow, and Trunk-Based Development—explaining their evolution, use cases, and drawbacks. It emphasizes that the right workflow depends on your team's maturity, product type, and deployment process, and offers practical advice for choosing and implementing one.

### Key Points

- **Introduction to Git Workflows** [00:01] — The video discusses how Git workflows have evolved over the last decade and why understanding this evolution helps teams make better decisions.
- **Subscription Request** [01:14] — The creator asks viewers to subscribe, noting that 80% of monthly viewers are not subscribed.
- **Why Git Workflows Exist** [01:59] — Git is flexible but inconsistent; teams create conventions to ensure consistency, making collaboration and deployments less stressful.
- **Git Flow Overview** [03:14] — Git Flow, introduced by Vincent Driessen in 2010, uses multiple long-lived branches (main, develop, feature, release, hotfix) for versioned releases.
- **Git Flow Use Case** [04:41] — Git Flow suits mobile apps or enterprise software where multiple versions must be supported simultaneously, and where regulated industries require traceability.
- **Git Flow Downsides** [06:56] — Git Flow slows down development, doesn't play well with continuous delivery, and even its creator now recommends simpler workflows for web apps.
- **GitHub Flow Overview** [08:56] — GitHub Flow is simpler: anything in main is always deployable. Create a branch, make changes, open a PR, review, merge, and deploy immediately.
- **GitHub Flow Use Cases** [10:16] — Ideal for web applications (SaaS, APIs) with continuous deployment, small-to-medium teams, and strong automated testing.
- **GitHub Flow Challenges** [11:44] — GitHub Flow doesn't handle multiple versions, requires discipline, and struggles with multiple teams on the same codebase.
- **Trunk-Based Development Overview** [14:37] — Trunk-Based Development (TBD) involves committing directly to main or using short-lived branches, integrating continuously, and using feature flags to hide incomplete work.
- **TBD Benefits** [17:18] — TBD reduces merge conflicts, provides fast feedback, and is associated with better deployment frequency and recovery times (DORA metrics).
- **TBD Challenges** [19:32] — TBD requires experienced developers, bulletproof testing, and a cultural shift; it can be risky for junior devs or weak test coverage.
- **Evolution of Workflows** [22:08] — Git Flow made sense in 2010 for versioned releases; the rise of SaaS and continuous delivery led to GitHub Flow and then TBD as teams sought more speed.
- **Hybrid Approaches** [24:53] — Many teams use hybrids, like TBD with release branches or restricting PRs for external teams, to balance speed and safety.
- **Practical Tips** [27:46] — Automate everything, document your process, use supporting tools (e.g., TBD Flow), measure DORA metrics, and iterate on your workflow.

### Conclusion

The best Git workflow depends on your team's maturity and product type; aspire to Trunk-Based Development but consider hybrids. Optimize for speed of feedback and evolve your workflow as you grow.

## Transcript

something that I think is super relevant for most development teams today. And that is Git workflows and specifically how they have evolved over time. Because
here's the thing, the way we work with Git, the way we branch, merge, and deploy code has changed dramatically over the last decade. And understanding why these changes happened will help you make much better decisions for your own
team. Now, if you've ever merged code on a Friday afternoon and immediately regretted all your life choices, you know exactly what I'm talking about. That usually happens when your team has no real branching strategy or worse, the
wrong one for what you're trying to achieve. So let's break down the three achieve. So let's break down the three main Git workflows that teams use today most commonly which are Git flow, GitHub flow, and trunkbased development. We
will look at how they evolved, why they exist, and most importantly when each one actually makes sense for your specific project. So let's get started. But first, a quick thing. We noticed
that 80% of people who watch our videos every month are still not subscribed every month are still not subscribed yet. Me and our entire video editor team are putting immense time and effort into each and every video to make it as
valuable and high quality as possible for you. So, if any of these videos have helped you at all, giving it a like and subscribing to the channel and becoming officially part of our community is the simplest way for you to support us and
it would mean the world to us. Seriously, thank you and let's get into it. All right, so first let me give you some context about why we even need different Git workflows. When Git was created, it
was designed to be very flexible. You could basically do whatever you wanted with branches and that's great for freedom but terrible for consistency across teams. So what happened is that teams started creating conventions
basically agreed upon ways of working so that everyone on the team would follow the same process and this made collaboration with git easier. It made code reviews a little bit more predictable and also made deployments
less stressful. But here's where it gets interesting. The right workflow for your team depends entirely on what you're building and how you're deploying it. Like are you building a mobile app that users download and install where you
need to support multiple versions running in the wild? or are you building a web application that deploys continuously to production multiple continuously to production multiple times a day? These two scenarios require
completely different approaches and that's exactly why we have these different workflows or why we had the evolution of these workflows over time. So let's start with the one that for a long time was considered the industry
standard but in the last years has become a complete bad practice which is git flow. Gitflow was introduced by Vincent Dre in
Gitflow was introduced by Vincent Dre in 2010 and for many years it became the branching model that everyone talked about and used in projects. The idea behind git flow is that you have multiple long lived branches in the
projects and I personally have used gitflow in many projects in my earliest engineering days. The idea behind git flow is that you have multiple longived branches each one serving a specific purpose. So you have a main branch for
production ready code. Develop branch which is work in progress code that more or less reflects the development environment and is mainly used for integration meaning all the code that is in progress is being merged into this
develop branch. Then you have feature branches for new work. So for every feature you have a dedicated branch for code related to that new feature. Then code related to that new feature. Then you have release branches for preparing
deployments or releases and you have hotfix branches for emergency fixes on production. When something breaks which is absolutely urgent and requires a fast
small fix, you basically do it with this hot fix branch. Now let me show you a real world scenario where this actually makes sense. Let's say you're building a mobile application. Your users are running different versions of your app.
Some of them are on version 2.3, some of them are on 2.4, some have already upgraded to 3.0. Now your product manager comes to you and says, "We need manager comes to you and says, "We need to fix a critical bug in version 2.3,
but we are already working on version 3.0." With Gitflow, this is actually straightforward. You create a hot fix branch from the main branch at the point where version 2.3 was released. You fix that bug and then you merge it back to
both main and develop. This way the fix goes into the current production version goes into the current production version and into future releases. So when does git flow actually make sense? First,
when you're building software that ships in versions, which was an old traditional way of doing things, think of use cases like desktop applications where you install the application on your computer, or mobile apps or
enterprise software that customers install on their own infrastructure versus accessing it directly online from the browser. Second, when you need to the browser. Second, when you need to support multiple versions of a software
simultaneously. So if you're maintaining version 2 something while developing version 3 something, Gitflow gives you the structure to handle those multiple versions and maybe do fixes in different versions. Third, when your team is large
and needs clear structure. So if you have many developer teams working on different features, having explicit branches for releases and hot fixes can branches for releases and hot fixes can prevent some chaos. And fourth, when you
are in a regulated industry where every change needs approval and traceability because Gitflow's structured approach makes auditing easier. But and this is
really important point is gitflow has some serious downsides and that's why it is actually considered a bad practice and most modern projects and teams do not use it. I have not used gitflow in many years because the alternatives are
just way better. So let's talk about those downsides. First of all, it really slows down your development and deployment cycle. All that branch management like creating release branches and merging hot fixes back to
develop, managing those longived feature branches, it adds so much overhead and complexity that your team is basically just spending a lot of time just managing the branches. Second, it does not play well with continuous delivery.
If you want to deploy to production multiple times a day or even once a day, having all these long lived branches creates a huge integration headache. You're constantly dealing with merge conflicts because people's work has
diverged for too long in these individual branches. So now developers are basically spending a lot of time just fixing the merge conflicts. And third, and this is a really interesting part, even Vincent Dreon himself, the
creator of Gitflow, later said that Gitflow is not suitable for web applications that deploy continuously. He literally updated his original blog post to say, "If you're doing continuous delivery, you should probably use a
simpler workflow." That's like the inventor of the fax machine telling you to use email instead. So, the ugly truth about Gitflow is this. It was designed for a specific era of software development. Back then when we had
version releases with slower deployment cycles and for many modern web applications, it simply does not work anymore. It is a total overkill. anymore. It is a total overkill. So this brings us to a second workflow
So this brings us to a second workflow called GitHub flow which emerged as a much simpler alternative to Gitflow in terms of complexity. If Gitflow was a five course meal, GitHub flow would be a really good sandwich. It's simple, fast,
it gets the job done. The core principle of GitHub flow is this. Anything in the main branch should always be deployable. That's it. Just one rule. And here is how it works in practice. You create a branch from main. You make your changes.
You open a pull request. You get it reviewed and merge it back to main. and you deploy it immediately. That's the entire workflow. So, let me give you some real use cases or scenarios for this. Let's say it's Tuesday morning.
You notice that users cannot upload profile pictures on your website. So, you create a branch called fix profile upload. You fix the bug. You get it reviewed over coffee. You merge it to the main and that fix is live in
production by lunchtime. Done. Simple as that. So when does GitHub flow make sense or what use cases is it perfect for? First of all, when you're building web applications that deploy constantly and continuously. Think of SAS products
like software as a service, APIs, web services, anything where there is only one version in production at any time. or in other words, anything that is hosted versus something that you install on your own device and it's hosted with
only one latest available version. Second use case is when your team is Second use case is when your team is small to medium-sized and moves fast. So you release your changes, your code changes, new features or bug fixes fast,
in which case you don't need the complexity of Gitflow's structure. The third is when you've got solid automated testing and CI/CD pipelines. Because if main is always supposed to be deployable, you need confidence that
whenever new code changes get merged into main, which happen daily in this case, any problems or issues will be caught by your extensive automated tests. And fourth, when you want to ship features instead of managing branches,
features instead of managing branches, which goes back to speed of deployment because GitHub flow basically gets out of your way and lets you focus on building and shipping things fast to the production instead of using most of your
time managing and juggling different branches. But GitHub flow also has challenges. First of all, it doesn't handle multiple versions. Everything merges straight to production. So if you need to support all the versions, GitHub
need to support all the versions, GitHub flow will not help you here. Second, it really demands discipline and this is where the culture of your team and proper guidelines are really important. If someone merges bad code and main gets
broken, your entire deployment pipeline stops. And since main is always supposed to be deployable, this is a big problem. And third, it can really struggle when you have multiple teams working on the same codebase because people may start
stepping on each other's toes and coordinating between those teams will become harder. So the ugly truth about GitHub flow is that it assumes your team already has good habits and they're in sync. But if your team treats pull
requests like optional suggestions and they treat testing like homework they forgot to do, you're probably going to regret using GitHub flow for your projects when you start fighting with all these issues that sleep all the way
all these issues that sleep all the way to production. But when it works, it works really well. And lots of teams today actually use GitHub flow because it's simple and not over complicated and it allows them to work really
efficiently and deploy fast. And I totally agree for the right projects with the right guard rails for the team it's fantastic. Now before moving on I it's fantastic. Now before moving on I want to give a huge shout out to MongoDB
who made this video possible. Speaking of building the right systems to support your team that applies to your data layer as well. So here's a common pain point. When you're moving fast with continuous deployment, most teams end up
with what's called a database sprawl. So you've got one database for operational data, another for search, maybe a vector database for AI features, and now you were spending time syncing data between all these databases instead of shipping
features. And if you're building with AI, which let's be honest, most teams are exploring right now and that's where the trend is going. Atlas vector search the trend is going. Atlas vector search lets you implement ragg or ra and
semantic search without adding another database to your stack. So it's built right in. MongoDB Atlas solves this by being a unified data platform. your
operational data, vector embeddings for AI, real-time analytics, it all lives together. No synchronization headaches, no managing multiple systems, and it runs on any major cloud provider, so you are not locked in. If this is relevant
for your project or work, head over to mongodb.com/atlas and you can start building for free. Link is going to be in the video description. Now let's talk about my favorite and
current industry best practice approach called trunkbased development which is what really high-erforming DevOps teams are increasingly moving toward. In most
of my devos projects that I've worked in in the recent years, this is the approach that either I have used from the beginning or transition towards as one of the goals of implementing proper DevOps processes. So with trunkbased
development, the way it works is some teams actually commit straight to main. Others use temporary branches that exist for maybe half a day before merging them back to the main. But the key principle is the same integrate continuously which
means it directly ties to one of the DevOps principles of continuous integration, continuous deployment. So this is the git workflow that supports this is the git workflow that supports that CI/CD principle of DevOps. So let
me show you a real scenario. Let's say three developers are working on different parts of the checkout feature of your application and they're all committing to main multiple times a day. Now you may be wondering, but that means
that the work is in progress. So they are committing half-done features into the main. How does that make sense? Well, here's a clever part. The trunkbased development usually uses what's called feature flex, which is
what's called feature flex, which is basically a switch that turns on or off the parts of the code that are still in progress. So it basically hides the incomplete checkout feature implementation from users. So the code
itself is in production because it's continuously integrated and deployed. But the feature is not visible to the users because it's disabled using feature flex which basically means it's not executed or it's hidden from users.
And as part of continuous integration, every small commit to the main triggers automated tests that try to catch any issues before they get deployed to the production. So again, those three developers are continuing to work on the
checkout feature and continuously deploying their commits, their small commits to the production using feature flags. By Friday, they complete their development. So the code is ready for production. So they flip the flag and
the new checkout is live in production. So it's not hidden anymore from the end users. It's live. And if we look at the impact of this, we have zero merge
conflicts because they've been integrating continuously all week in small bite-sized commits and automated tests have been checking every small code change immediately giving the
developers very fast feedback loops. So something broke they can immediately fix them. So when does trunkbased development really shine? First of all, when your team consists mainly of experienced developers, I wouldn't say
senior because you may have mid-level developers who are very disciplined and write clean code who work really well together and are well in sync. Second, when you've got bulletproof automated testing, that's where trunkbased
development works the best. But this part is actually a non-negotiable because think about this. If you're continuously deploying your code changes to production, you need to be extra careful and extra confident that you're
careful and extra confident that you're not deploying buggy or insecure or bad code to the production. And if you don't have strong tests or extensive tests that really cover all aspects of your code and application, trunkbased
development is too risky. Third, when you want rapid integration and faster deployment, that's when trunkbased development is the best approach. There's a research from Dorometrics that shows that teams using trunkbased
shows that teams using trunkbased development, also known as TBD, have much better deployment frequency as well as faster recovery times. So, if production, they can recover much faster, which makes sense because you're
continuously deploying to production. So every code change has a rapid iteration cycle and finally it really shines for use cases where you're shipping SAS products that continuously get updated and there is only one version in
production. But here comes the flip side of this and this is very critical. Trunkbased development also comes with real challenges. First of all, if you have junior developers or inexperienced developers who are not used to working
developers who are not used to working with clean Git workflows or people who you just don't fully trust, they can break production accidentally. Especially if your test coverage is not super extensive. So if someone commits
bad code directly to main and your tests don't catch it, you're in trouble. And that automatically means that for trunkbased development to work, you need proper systems and guard rails to prevent this. So instead of relying on
people knowing how to work with git workflow and that they behave so to say, you need to build a system that is solid enough that prevents anyone from accidentally damaging your production. Second is when your test coverage is
weak. That's when trunkbased development will bring absolute chaos to your thing because [clears throat] it immediately exposes that weakness and it
shows you clearly that you need proper test coverage. Third, and finally, it test coverage. Third, and finally, it requires a cultural shift because teams need to think differently about how they work. The individual developers need to
work. The individual developers need to learn the concept of TBD and how to make smaller commits, how to use feature flex, understand continuous integration. So it's not just a technical change, it's actually a mindset change. So the
ugly truth about trunkbased development is that it feels reckless until you realize that it forces you actually to build the automated testing you should have had anyways in the first place. I think of it like removing training
wheels, which is scary at first, but it's faster once you get it and once you learn how to use it properly. And the reason why trunkbased development fits
perfectly into the DevOps philosophy is because it doesn't work without strong CI/CD pipelines, automated tests, and the culture of quality. And interestingly, most engineers who have really nailed the trunkbased development
in their projects absolutely believe that it is the best approach and would never switch to alternatives. That's how convincing it is once it really works. And if this resonates with you, share your experience below so others who
aren't using TBD yet can learn from your experience as well. And rightfully so, they would tell you that high performing teams can only do trunkbased development. There is no other option. So if you get it right, you won't look
for alternatives. So now let's talk about why these workflows evolved the way they did. Gitflow made perfect sense in 2010. Back then most software was shipped in versions. He released version 1.0 then
worked on version 2.0 for months before releasing again and deployment process was risky, manual, infrequent and obviously this was before DevOps days and unfortunately there's still many projects that work this way.
That's why DevOps engineers are still so valuable and highly demanded because that's exactly type of problems that they fix and optimize. So then something changed in the industry. We had a rise of SAS and continuous delivery. Suddenly
of SAS and continuous delivery. Suddenly companies like Amazon, Netflix, Spotify were deploying to production multiple times a day. They were not shipping versions, they were shipping features continuously and Gitflow just didn't
make sense for this way of working because it just couldn't keep up with the speed. So all these long lived branches, all that merging overhead, it was just too slow if you wanted to release really fast. So teams started
simplifying. That's how GitHub flow emerged as a faster, leaner alternative for teams that wanted to deploy continuously. But even GitHub flow had limitations. Pull requests could still become bottlenecks or branches could
still leave too long. So teams wanted even more speed and that's where trunkbased development came in. By committing directly to main or using very shortlived branches, teams could integrate continuously. So we had a a
rise of continuous integration on top of continuous deployment and they could now deploy faster than ever before. But here's something important. This evolution only made sense because the underlying technology improved. In 2010,
automated testing was not as mature as it is now. CSD pipelines were much harder to build. Feature flags did not exist in the way that they do today. But today, we have amazing tools for automated testing, continuous
integration, continuous delivery, feature management, deployment automation, and that makes trunkbased development much easier and possible in a way that it wasn't before when it first emerged. So the evolution is not
just about workflows. It's about the entire ecosystem of tools and practices that support them. Now let's look at some real world
reflection of these workflows because theory does not always translate to practice. One interesting thing is that many teams actually use a hybrid many teams actually use a hybrid approach of multiple git workflows like
GitHub flow and trunkbased development. And I think that's actually really common that most teams don't follow a standard workflow or a textbook workflow. They kind of adapt each one to their own specific needs. uh like there
are teams that use trunkbased development with release branches which is again the TBD workflow adjusted slightly with custom approach. So that means they're committing to main frequently but when it's time to release
they create a release branch for stability which can be a smart compromise if you're not fully ready to flip the switch but you want to kind of slowly get there. There are also some people who use trunkbased development
people who use trunkbased development who enforce the stability by for example restricting collaborating teams to creating PRs. So that means they're little bit more careful with external teams because they don't want them to
take down production with a simple typo. So they create these automatic guard rails to minimize any unnecessary risk. So basically the core team would use trunkbased development because they're in sync and they trust each other and
they have good testing in place but any external team would have to use pull requests for an extra layer of safety. And it's important to know that these hybrid approaches exist because it shows that you can mix strategies or adjust
one specific git workflow slightly based on your project's needs or who's looks like and so on. And again, trunkbased development is the most beloved workflow out there and people who actually use it definitely think
who actually use it definitely think it's the best. Now I personally 90% agree with that because I think there are valid reasons to use GitHub flow or Gitflow for certain projects that are not mature enough to use trunkbased
development. So they shouldn't jump to it straight away. They should slowly fix the underlying issues they have so they could move eventually to trunkbased development because the underlying point of trunkbased development is actually
valid which is if you want to be a high performing team you need to invest in the practices that enable trunkbased development which is strong testing CI/CD feature flags culture of continuous integration and so on which
continuous integration and so on which are basically part of DevOps practices. some practical tips for implementing a proper Git workflow in your project.
proper Git workflow in your project. First step, automate everything you can. No matter which workflow you choose for your current project with the current limitations, automation is your friend and that should be the first step you
start with. Automated tests, automated CI/CD pipelines, linting, code formatting, automated security scanning and testing. Automate everything. There are so many tools out there that allow you to do that. Second, very important,
document your process. Write down your team's branching strategy, commit message conventions, code review expectations, pull request workflow details that everyone should follow. Don't assume everyone knows the rules
because documenting will increase consistency for each individual engineer in your team. Third, use tools that support your workflow. For example, if might want to check out a tool called TBD Flow, which is a command line tool
that helps you stay in flow with trunkbased development. It will committing to main or creating short-lived branches and enforcing conventional commit messages. Next one is measure your performance. And this
might be new for a lot of teams who have never done this before but track metrics like deployment frequency, lead time for changes, time to restore service. If you
want to get a clear picture of how Git workflow and these underlying improvements like automated testing and so on actually make your team more efficient and these are called Dora metrics that very clearly show you if
your current workflow is actually working and making your team slow or working and making your team slow or fast and finally iterate. Your workflow should evolve as your team and product evolves. So don't be afraid to change it
if it's not working anymore. Do not get stuck by using a workflow that you considered a standard either in industry or in your team or company just because or in your team or company just because you have been doing it for many years.
So the key takeaway is this. The git workflow you should aspire to is trunkbased development. But there are valid cases for other use cases plus
hybrid approaches depending on the maturity level of your team and underlying systems. So there is no onesizefitsall answer because the best
workflow is the one that fits your team, your product and your deployment process currently right now the best. But if I have to give you one piece of advice, it is this. Optimize for speed of feedback.
The faster you can get code from a developer's machine to production, the faster you can learn and improve. And that usually means simpler workflows, not more complex ones. So, pick what fits your team, faster tests and more
extensive tests, and don't be afraid to evolve as you grow. So, that's it for this video. If you found this helpful, make sure to share it with one colleague or friend who you think will benefit from this knowledge as well. Or share it
with your team if you're thinking about changing your Git workflow. And let me know in the comments which Git workflow your team currently uses and whether it's actually working for you. Share your experience with others in the
community because we can all learn from each other. And I would really love to hear your real world experiences. And with that, thanks for watching and I'll with that, thanks for watching and I'll see you in the next video.