Most branching strategy discussions turn into theoretical debates about Git Flow versus trunk-based development. Here's what actually matters when you have limited time.

Should we use feature branches or commit directly to main?

Depends entirely on your team size and deployment frequency. Two developers deploying twice a week? Short-lived feature branches or even direct commits work fine. Ten developers shipping multiple times daily? You need a real strategy or you'll spend half your time resolving conflicts.

How long should feature branches live?

No more than two days if you can help it. Every day a branch exists, it diverges further from main. That divergence creates merge conflicts. I've seen week-old branches take four hours to merge cleanly. The same work in one-day increments? Maybe twenty minutes of conflict resolution total.

What's the deal with release branches?

Only create them if you're supporting multiple production versions simultaneously. Supporting version 2.1 while developing 3.0? You need release branches. Everyone's always on the latest version? They just add overhead.

Do we really need develop and main branches?

Not unless you have a specific deployment workflow that requires it. Many teams cargo-cult this pattern from Git Flow without understanding why it exists. If your main branch always matches production and you deploy from it, adding develop just creates an extra merge step.

How do we handle hotfixes efficiently?

Branch from production, fix it, merge to both production and your development branch. If you're using main as production, that's one target. Tag the hotfix commit so you can find it later.

The pattern that works: keep branches short, merge frequently, and only add complexity when you have a concrete problem to solve. Start simple, add structure when the pain points become obvious.