Subscribe
Sign in
p/bucketFeature flagging that's purpose-built for B2B
Start new thread
flo merian

Trunk-Based Development vs GitFlow — What's your dev workflow?

11
•
In software engineering, trunk-based development (TBD) is a strategy to manage git workflows that favours merging commits into the `main` branch even before the feature is fully complete, instead of the git flow that favours working on long-lived branches until features are 100% complete. TBD or GitFlow: What's your current developer workflow?

Add a comment

Replies
Best
Alex Gap

At @Product Hunt , we're closer to the trunk-based development approach, focusing on smaller PRs and making heavy use of feature flagging.


This allows us to iterate quickly and gather feedback early. By shipping parts of a feature incrementally, we can get input from team members much faster than if we'd wait for a feature to be "100%" complete.

André J
@product @lagap Talking about feedback. Comments doesn't always load atm. Esp in launches with lots of comments. Check the Tana launch from this week with 500++ comments. it's a bit sporadic. Sometimes it works sometimes not.
Alex Gap

@sentry_co I'll take a look 👀

flo merian
Launching soon!
@lagap fully agree! ooc — what tool do you use for feature flagging at Product Hunt?
steve beyatte
I've only really been exposed to GitFlow. Does trunk-based development create a ton of overhead with code review? Seems like there'd be a lot of reliance on CI/CD tools and test coverage and team communication. Can distributed teams really move faster like this?
Ron Cohen
Launching soon!
@steveb if you have smaller commits/pull-requests which trunk-based development favors, you can argue you’ll have more, but smaller reviews. I think that’s a good thing though. Big PR = LGTM while a smaller PR often has more detailed comments. I don’t think I can see how there needs to be more team communication with TBD?
Odin Urdland
At Tana we follow Chromium's development model. It is closer to trunk-based development, but has some other nice characteristics. When we decide to do a release we choose a merge on main to release, that will get its own branch. It is tested for a while 2h-ish of internal work happening there before it is pushed to the stable branch. If we fix some bug and want it out fast we will first merge it to main, then cherry pick that single merge on top of the stable branch and push that out again. Chromium actually let's the release branch go through dev, beta channels before it hits stable, but we only have main and stable. So it is simplified. Every merge has a readable version number (increases by 1 every merge since the last major version bump). Every commit on a non-main branch will increase the last number in the version number. So you can see what main it was branched off on, and how many patches were applied away from that main-point.
Ron Cohen
Launching soon!
At Bucket, we do something closer to trunk-based development. By the way, I think a common misconception is that you cannot have branches or you cannot have PR reviews with TBD. But you totally can have both!
Prashant Lakhlani
Launching soon!
I've done both but Gitflow is something I'm following for a very long time now.
flo merian
Launching soon!
@plakhlani interesting! what makes you stick to GitFlow? what are the benefits from your pov?
Vishal

Great topic, Flo! Trunk-Based Development (TBD) is great for fast-moving teams, but it needs solid CI/CD and feature flags to avoid breaking things. GitFlow, on the other hand, works well for structured releases but can slow things down.

For us, TBD with short-lived branches strikes the right balance—quick iterations without sacrificing stability. Curious, what’s been the biggest challenge for teams switching from GitFlow to TBD?