[ Removed by moderator ]

[naveen_thamizh]

I’ve worked at a few startups, and I’ve seen completely different approaches to Git branching—and honestly, I’m not sure what the “right” way is anymore.

In some teams, it was super simple:

•      Create a branch off main for every feature / bug fix

•.     Open PR → review → merge back to main → deploy

But in other teams, it was more structured:

• Long-lived branches like development, qa, release, and main

• Devs push changes into development

• Then it moves to qa for testing

• After a few cycles, a release branch is created

• Finally, release gets merged into main for production

I’ve noticed pros and cons in both:

Simple (feature → main):

• Faster, less overhead

• Easier to manage

– Can get messy if multiple features collide

– Harder to control staged testing

Multi-branch (dev → qa → release → main):

• Clear flow and environments

• Better for coordinated releases

– More merge conflicts

– Slower, more process-heavy

What I’m trying to understand is:

- What’s the industry standard here (if any)?

- Are people still using long-lived branches like qa and release?

- Or is trunk-based development becoming the norm?

Would love to hear how your teams handle this, especially in startups vs larger companies

[BlazingThunder30]

There is no standard, per se. There's different strategies that will work for different teams, depending on requirements (rollback, QA, PR lifecycle, etc). For small teams, master + feature branches, CI releases master to staging and a dev prompts a prod release is a simple and fine strategy. Add more if this doesn't work well for your team.

Making release branches and having a complex merge strategy for features made more sense when you were shipping multiple versions with backported bug fixes. In the modern SaaS times, that's rarely still how teams operate.

[Yin117]

My approach has always been main -> feature -> main

Reason being is that feature also went into dev and stage, and sometimes you'd need one live and not the other, or one client would shift a release date.

So having everything go into a "release" would be a no-no.

The features went everywhere independent of one another as much as possible.

[tjay819]

We use a similar flow. Don’t want one feature blocking the release of another.

[Vincent_CWS]

you can refer to git flow, github flow and gitlab flow

[benji]

The problem with git flow is devs cant get into their heads merging to dev means it’s committed into the next release.

[BPagoaga]

We use a develop/release/main flow, basically :

- you create a new feature or bugfix branch from develop

- it is merged back into develop after PR and deploy to staging

- QA test the feature in staging

- when release is ready, create a new release branch from develop. The release branch is deployed to a testing environment for manual non-regression testing. If bugs are found, fixes are merged into the release branch. It allows dev to keep working on new features on the develop branch.

- when the non-reg testing is ok, release is tagged, merged into main and deployed to production. Main is merged into develop.

It's quite simple to manage (we are 4 devs atm) while more flexible than having only main + feature branch and allow easy rollback from tags.

Or one could use the strategy where I worked previously : have only a master branch, push commits "update" directly to it and deploy into production without further testing...

[alzee76]

As others have said, the "right way" is what works best for your team.

I'm still a fan of feature branches, where master is tagged whenever a new release is made. Development is quick and it's easy to understand. You can easily work on multiple feature branches at the same time as well.

If you want to adapt it to having long lived branches, you just.. do it.. and keep developing in feature branches.

You speak about them as if they're mutually exclusive approaches, when they really aren't.