Git Branching Strategies - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Branching sounds like a small detail until two people change the same file. Then someone has to figure out which version is the real one, and that's a branching problem. A branch is just a safe copy of your project, and a branching strategy is your team's rule for how those copies come back together. There are three big ones git flow, GitHub flow, and trunk based development, and each one was built for a different kind of team. By the end, you'll know which one fits yours and which mistakes to avoid. Welcome to the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. What a branch is. The word branch sounds technical, but the idea behind it is simple.

0:41 A repository is your project folder with its whole history saved by git. That means every version of every file going all the way back to the first day. And a branch is a copy of that project. You can change without touching the real one. Nothing gets locked and nothing gets deleted. When you create a branch, you're really just saying that you want to try something without breaking the version that already works. That's why. Branching starts to feel safe after you've done it a couple of times. The main branch, which some teams call main and others call master, is the copy everyone treats as the working version of the project. If you've seen both names and wondered whether there are different things, they aren't. Main and master mean the same thing, and the switch from one name to the other was a naming choice, not a new feature you have to learn. Branches in git are also cheap, and that's the part people coming from older tools find hardest to believe in the systems that came before git.

1:26 Making a branch was a slow, heavy operation. You did rarely and carefully in git it happens instantly, which is why modern teams branch for almost everything. If you've heard people mention a commit that's just a saved checkpoint one recorded change with a message attached to it. A branch is really a moving label that points at a line of those checkpoints, which is why switching between branches is so fast that one idea is the whole foundation. Every strategy and every argument between developers comes down to a single question about how those copies get made and how they come back together. Why branching strategies exist. Once a team grows past one person, the rules start to matter. Git makes branching cheap and merging easy, which is a big change from the older tools where merging felt scary and rare. Vincent Driessen, the person behind Gitflow, made this point himself in git.

2:07 Branching and merging moved into the everyday workflow. Instead of staying a special event you scheduled weeks in advance. Cheap branching creates a new problem, though. If everyone makes copies whenever they want, and nobody agrees on how those copies come back together, the work collides. Someone's half finished change gets mixed into something that was supposed to be done, and now the team can't ship either one of them. Picture a developer halfway through a redesign while a teammate quietly fixes a bug in the same file. Both changes land in the same place, and no one was expecting it. A branching strategy is the fix, and it's less glamorous than it sounds. It's not software you install, and it's not a setting you flip once and forget. It's a shared agreement about who works where, how long a branch is allowed to live, and how changes get reviewed before they land in the main version.

2:49 When that agreement is missing, you get the mess from the start of this episode. Two people, one file, two versions of the truth, and nobody is sure which one is real. A strategy is how a team stops that from happening twice. The three building blocks. Almost every strategy is built from the same three kinds of branches, and once you know them, the model stops sounding like a foreign language. The first is the main branch, the always working version that you ship from. It's the one branch that never disappears. The second is the feature branch, and this is where the actual work happens. You create one for a single task, like adding a login page or fixing a broken button. You name it after the work so anyone can tell at a glance what it's for. Feature branches are meant to be temporary, and the moment the work is merged in, the branch gets deleted.

3:29 The third is the release branch, and it only shows up when you ship in numbered versions. It's a way of freezing a snapshot for final checks. You cut it when the code is almost ready, use it to fix last minute bugs and give it a version number before it goes out to customers. That's the full toolkit. What separates the three big models comes down to how much they branch. Git flow uses all three plus a second permanent branch. GitHub flow mostly just uses main and feature branches. Trunk based development pushes almost everything straight into main and barely branches at all. One more piece is worth naming, even though it's not a branch. A pull request is how a finished branch gets reviewed and merged, and it shows up in every modern strategy. We'll come back to it because it's the everyday mechanic you'll use most. Git flow.

4:09 The structured one. The most famous strategy has a specific birthday, and knowing it helps explain why it looks the way it does. Vincent Driessen published Git Flow in January twenty ten in a post called A Successful Git Branching Model. For years afterwards, it was the default answer. Whenever anyone asked how to use branches, git flow runs on two permanent branches. Master holds code that's ready for production at any moment and develop holds everything that's finished but not yet released. Those two never go away and all the other branches orbit around them. Feature branches come off, develop and merge back into. Develop. Release branches, come off, develop, get their final polish and then merge into both Develop and master hotfix branches. Come off master to fix something urgent in production and they merge back into both as well.

4:49 So the fix isn't lost in the next release. That structure earns its keep. When you ship inversions, say you support version two, while version three is in progress and a customer on version one needs a patch. Gitflow gives you a clear, well marked place to do that work. But here's the twist and it surprises almost everyone. In March twenty twenty, ten years after publishing the post, Dreessen added a note at the top of his article. He wrote that Gitflow had been treated like a dogma instead of a choice. It wasn't designed for web apps delivered continuously, he said, and teams shipping that way should adopt something simpler, like GitHub flow. His closing line is worth remembering Panaceas don't exist, so consider your own context and decide for yourself. For the teams it was built for. None of that is a problem if you're building software that's explicitly versioned or you support several versions out in the wild, the model can still fit as well as it ever did.

5:36 GitHub flow. The simple one GitHub flow came at the problem from the opposite direction. Scott Chacon wrote it up in August twenty eleven, and the whole point was that GitHub itself didn't use git flow at all. The reason was simple GitHub deployed to production every day, often several times a day, and a process built around releases simply didn't fit that reality. So they stripped it down to one hard rule and a short list of steps. The rule is that anything in the main branch is deployable, which means main is always safe to ship from and always safe to branch off. To start work, you create a new branch off main with a clear name, something like add login page or fix broken button. From there you push your work to that branch often, so it's backed up and so everyone can see what you're working on when you want feedback or when you think the work is done.

6:19 You open a pull request, someone reviews it, the tests run, and once it's approved, you merge it into main. Then you deploy right away because main is supposed to stay shippable at all times. That's the entire flow. No develop branch, no release branch, no hotfix branch, just main and short lived feature branches. At the time, GitHub had thirty five employees with roughly fifteen to twenty of them working on the same project at once. Chacon's post shows six different people deploying about twenty four times in a single day. The trade off is that it assumes you can deploy on demand, and that you don't have to support old versions for a web app or a small team. That's usually true, and the simplicity is worth a lot when you're getting started. If a branch does hang around longer than you meant it to, the fix is to merge the latest main back into it so it doesn't drift while you work.

7:01 Trunk based development. The fast one. If GitHub flow is simple. Trunk based development is the lean version of simple. Everyone commits small changes into one shared branch. The trunk, which is just another name for main branches. When they exist at all, live for hours instead of weeks. That short lifespan is the whole idea, and it's worth sitting with for a moment. The longer a branch stays alive, the more the rest of the project moves on without it, and the messier the merge gets when it finally comes back. Short branches mean small mergers, and small mergers are the ones you can fix in a minute, rather than an afternoon release. Branches are optional here. They're just snapshots you cut when you need to mark a version. If you deploy many times a day, you don't need them at all because the trunk itself is always shippable. The evidence behind this one is worth knowing because it's more than a preference.

7:44 Someone had Dora, the research program that studies how teams deliver software, looked back at its own data from twenty sixteen and twenty seventeen, it found that teams perform better when they keep three or fewer active branches merged to trunk at least once a day, and skip code freezes and separate integration phases. Google is the famous example of this way of working, and the practice goes back a long way there. That's part of why the model keeps showing up whenever people talk about fast teams. The catch is that it asks more of you than the other two. You have to break your work into small pieces and trust fast automated tests, because there's no long stabilization period to catch problems at the end. That's why trunk based development works best on teams that ship constantly and have invested in testing. It's also the model most likely to feel unfamiliar if you're starting out. There's no long lived branch where you can hide unfinished work.

8:28 Pull requests explained all three strategies lean on the same tool for bringing work together, and it's the one you'll touch every single day. A pull request, usually shortened to PR, is a request to merge your branch into another branch. It comes with a built in place for people to review the change first. It's less of a button and more of a conversation. Reviewers can comment on individual lines, ask questions, and request changes. You keep pushing more commits to the same branch and the pull request updates as you go. It becomes a running record of the discussion until everyone is happy and the change is ready to merge. The value is all in the timing. Review happens before the change reaches main. That means mistakes get caught while they're still cheap to fix, instead of after they've shipped to customers and started causing trouble.

9:09 GitHub didn't invent the idea of reviewing code, but it popularized the pull request, and the feature dates back to around two thousand and eight. Today, almost every git host has its own version of it. Even when the name changes a little. There's also a social side that matters in a minute. The moment you open a pull request, other people can see your branch and start building on it, which quietly turns that branch into a shared thing. Hold on to that thought, because it's exactly why one of the rules coming up exists. Merge versus rebase. Once a pull request is approved, you have to fold your work back into main. And there are two ways to do it. They look similar on the surface and they behave very differently underneath. Pick the wrong one on the wrong branch and you can wipe out a teammate's work. So this next part matters more than it sounds. Merging combines your branch with main and adds a merge commit that records both histories at once.

9:51 Nothing is rewritten and nothing is lost. You can always see that two lines of work came together on a certain day. That record is useful when you're later trying to figure out what changed. And when rebasing takes a different route, it picks up your commits, moves them so they sit neatly on top of the latest main and creates brand new commits along the way. The result is a clean straight line with no merge commits, which a lot of teams find much easier to read. The trade off is the part beginners tend to miss. Merging keeps the full story exactly as it happened. Rebasing makes the story tidier, but it replaces the original commits, so the record of when the work was folded and disappears. That leads to one rule, and it's the most important rule in this whole episode. Never rebase a branch that other people are working on. Atlassian puts it as a single question to ask before every rebase, which is whether anyone else is looking at this branch.

10:34 If the answer is yes, you don't rewrite it. The reason it bites so hard is that a rebase on a shared branch breaks everyone else's copy. Your history no longer matches theirs, and a force pushed to sort it out overwrites the work they were still building on. If you're ever unsure, just merge Savory Base for your own private branch where it's a great way to tidy up messy commits before you open the pull request and leave shared branches alone. Choosing a strategy for small and large teams. Choosing comes down to a few plain questions about your team, not to which model sounds the most professional first, how often you ship. Second, whether you support old versions that people still use. Third, how many people touch the same code at the same time? Fourth, how much you trust your automated tests. Those four answers point toward a model far faster than any comparison chart, and they're the questions that matter if you're a small team or working on your own.

11:21 GitHub flow is usually plenty. One main branch and short feature branches will carry you a long way, and you can always add structure later if you need it. If you ship version software or you have to support several released versions at once, git flows, release and hotfix branches earn their keep. That's the world it was built for, and in that world, it still works well if you're a larger team that ships continuously and you've put real effort into automated testing. Trunk based development keeps your merges small and your releases frequent. That's exactly the trade it's asking for. One more thing is worth holding on to. Even the author of Git flow says there's no single right answer. You pick the model that fits your context and you change the choice when your context changes. A good way to start is to pick the lightest model that works.

12:02 Then add ceremony only when something breaks. Teams often adopt Gitflow because it looks impressive. Then find the extra branches cost more than they save. Common mistakes beginners make. Whichever strategy you land on, a handful of mistakes trip up almost everyone in their first year, and none of them are exotic. The biggest one is letting feature branches live for weeks. A branch that old has drifted so far from main that the merge turns into a fight. So keep branches short and merge them, often working straight on main with no review feels faster, right up until a broken change reaches your users, and there's nothing standing between it and them. Then there's the branch you rewrite while other people are still using it. Rebasing or force pushing over someone else's work is the mistake that ruins a teammates day because their history stops matching yours.

12:43 Stuffing unrelated changes into one branch or one pull request is another common one. It makes review slow, and if you need to undo something later, you can't separate the good change from the bad one. Copying a big company's setup without their testing and release process is tempting, and it rarely works because the model isn't the magic on its own. The practices around it are. The last one is quieter. If you treat the strategy as your own personal preference and you're the only person following it, then it's not really a strategy yet. It's just a habit. Every one of these is a normal way for a team to lose an afternoon, and every one of them has a simple fix. Which one fits you? So that's the whole picture. A branch, as you've seen, is a safe copy of your work, and a branching strategy is the agreement your team makes about how those copies come back together.

13:25 Git flow is the structured one built for software that ships in numbered versions. GitHub flow is the simple one built for teams that ship continuously. Trunk based development is the fast one, and it suits teams that can commit to small changes and strong tests. And when it comes to folding work, back in, merge keeps your history while rebase tidies it up and belongs on private branches only. Subscribe to M365 FM to keep learning the tools and the mindset shaping the future of work. And here's my question for you. Which branching strategy does your team use right now? And was that a real decision someone made or just a habit nobody has questioned yet?