[EN] Git im Team: Der Unterschied zwischen Feature-Branches und Trunk-based Development

Git is a team sport: Why we need strategies

When you start working on your first projects, Git is usually pretty simple: you write code, do a git add, then a git commit and finally a git push. Complete. You are the only author and the main branch belongs solely to you.

But once you start working in a team, the game changes drastically. Imagine five people writing the same novel at the same time. If everyone just writes random sentences in the manuscript, it ends in chaos. Sentences are overwritten, the plot no longer makes sense and in the end nothing works.

It’s the same in software development. We need “rules of the road” that govern how and when code from different developers is merged. We call these rules branching strategies.

Today we’ll look at two of the most well-known philosophies: the classic feature-based development and the fast trunk-based development.

The classic: feature-based development

If you’re starting out at a company or doing open source on GitHub, you’ll most likely encounter this model first. It’s the standard for many teams because it feels safe and orderly.

How it works

The basic idea is isolation. For each new task - be it a new button on the login page or a bug fix in the database - you create your own branch (a “branch”) that branches off from the main code.

The typical workflow looks like this:

1. Create branch: git checkout -b feature/new-login-button
2. Coding: You work on this feature in your own bubble for days. Nothing you do here bothers your colleagues.
3. Pull Request (PR): When you’re done, you tell the team, “Hey, I’m done, please look at my code.”
4. Review: Your colleagues check the code, give feedback and you make improvements.
5. Merge: Only when all thumbs are up will your branch be integrated into the main branch.

Der Vibe: “Safety First”

Feature-based development often feels relaxed. You have no pressure to share unfinished code. The ‘main’ branch is considered the holy grail - it is (theoretically) always stable because only tested code is allowed into it.

The Shadow Side: The “Merge Hell”

The problem often only arises at the end. Imagine working on your feature for two weeks. During this time, your colleagues have already merged 50 other changes into the main branch.

If you now try to merge your code, it crashes: Merge Conflicts. Your changes no longer match the rest of the application. What started as a relaxed development often ends in hours of work to resolve conflicts - the dreaded “Merge Friday”.

All right, let’s move up a gear now. Here comes the second part of the article.

We will now look at the model that companies like Google or Meta use and draw the conclusion at the end.

The fast lane: trunk-based development

If feature-based development is like writing chapters in separate Word documents, then Trunk-based development is like collaborating in a Google Doc in real time.

How it works

Here’s the radical idea: There are (almost) no long-lived branches anymore. All developers commit their code directly to the “main” branch (often called the “trunk”) – several times a day. If branches are used, they only live for a few hours, a maximum of a day.

Der Workflow:

1. Pull: You get the latest version from main.
2. Code & Test: You write a small change and test it locally.
3. Push: You immediately push the code back to main.

“But won’t I ruin everything?”

This is the first question that anyone who hears about it for the first time asks. If everyone keeps pushing unfinished code to main, the software is constantly broken, right?

This is where two indispensable bodyguards come into play, without which trunk-based development would be suicide:

1. Automated testing: Before code is accepted, a pipeline (CI) runs that checks whether everything still works. If the tests are red, the push is rejected.
2. Feature Toggles (Flags): This is the most important trick. You build your new “login button” directly into the code, but you hide it behind an invisible switch (if (featureEnabled) { ... }). The code is there, but the user doesn’t see it yet. This allows you to integrate unfinished features without disrupting the live environment.

The Vibe: “Sync”

The big advantage is: You are no longer afraid of merge conflicts. Since you compare your code with others’ code several times a day, conflicts are tiny and can be resolved immediately. The team moves forward as a unit. This is called Continuous Integration in the truest sense of the word.

Feature vs. Trunk: The direct comparison

Which path is right for you? Here is the decision-making aid:

Feature-based development is strong when…

• You open source: You can’t trust every stranger to write directly to your main branch. Here the review process is essential as a gatekeeper.
• The team does not yet have a strong testing culture: If there are no automated tests, trunk-based development is too risky. The manual review in the feature branch is then your safety net.

Trunk-based development wins when…

• Speed ​​matters: Modern high-performance teams want feedback in hours, not days.
• The tests are good: If you have solid test coverage, you don’t need to be afraid of the ‘main’ branch.
• You hate “Merge Hell”: If you spend more time resolving conflict than coding, it’s time for a change.

Conclusion: It’s a journey

At the beginning of your career, Feature-based Development gives you the security you need. It’s okay to code in your own “bubble” and only come out when everything is perfect.

But the more experienced you become, the more you will appreciate the benefits of Trunk-based Development. It takes discipline and courage, but it rewards you with a workflow that is incredibly fluid.

My tip for you: Ask in your next team meeting: “How long do our branches actually live on average?” The answer tells you a lot about what makes the team tick.