Git Flow vs trunk-based — which to choose?

Git Flow (develop + release + feature branches) suits projects with releases every few weeks or months that need parallel versions in production. Trunk-based (everything in main, feature flags) suits CI/CD daily deploys. For most SaaS — trunk-based. For desktop software and mobile apps — Git Flow.

Do I have to create a develop branch?

No. develop is justified when there is a big gap between a feature being done and reaching production (QA, translations, release cycle). If you deploy every PR to main, develop is an extra layer. Many modern teams run main + short-lived feature branches, with no develop at all.

What to do with a long-lived feature branch?

Regularly pull in main via rebase (if the branch is yours) or merge (if it is shared). At least every 3 days. The longer a branch lives, the more conflicts at the final merge. If a branch is over 2 weeks old, ask yourself whether the feature can be split into parts and merged incrementally.

Squash merge or rebase merge?

Squash — for PRs with 5+ WIP commits: one clean commit in main, linear history. Rebase merge — when the commits are already meaningful and you want to keep the detail (refactor + tests + docs). Merge commit (no-ff) — when it matters to see that a separate feature happened here. The team picks one style and sticks to it.

Git flow: working with branches the right way

Contents

Why branches matter

A branch is an isolated copy of the code. You build a new feature on your branch without touching the working code in main. If something goes wrong — just delete the branch. (Before your first commit, check your .gitignore — junk in the repository is hard to clean up later.)

Main branches

main (or master)

The primary branch. Always working, production-ready code. Never commit directly — only through merge or PR.

develop

The development branch. All completed features merge into it. When a release is ready — merge into main. Used by teams; for solo projects often unnecessary.

How to name branches

# New feature
feature/user-authentication
feature/dark-mode

# Bug fix
fix/login-redirect
fix/mobile-menu

# Urgent production hotfix
hotfix/payment-crash

# Refactoring
refactor/api-layer

Typical workflow

# 1. Sync with main
git checkout main
git pull origin main

# 2. Create a branch for the new feature
git checkout -b feature/new-navbar

# 3. Work, commit
git add .
git commit -m "feat: add responsive navbar"

# 4. Push the branch
git push -u origin feature/new-navbar

# 5. Open a Pull Request on GitHub
# 6. After review — merge into main, delete the branch

Merge vs Rebase

Merge — creates a merge commit, preserves full history. Good for public branches. (A deeper comparison with real-project examples is in rebase vs merge.)

git checkout main
git merge feature/new-navbar

Rebase — moves your feature commits on top of main, history stays linear. Good for local branches before pushing.

git checkout feature/new-navbar
git rebase main

⚠️ Never rebase public branches that others have pushed to — it rewrites history and creates conflicts for everyone.

Deleting branches

After merging it's better to delete branches — they clutter the list.

# Delete locally
git branch -d feature/new-navbar

# Delete on remote
git push origin --delete feature/new-navbar

💡 GitHub repo settings have an "Automatically delete head branches" option — branches are removed automatically after PR merge. All commands from this series on one page — in the git cheat sheet.