GitoryxA solid Git branching strategy is the backbone of any professional development workflow. This guide covers everything from basic branch creation to team-wide strategies like GitFlow and trunk-based development.
Your team is working on multiple features at once, hotfixes keep colliding with new code, and your `main` branch broke twice this week. The root cause is almost always the same: no clear branching strategy.
A Git branching strategy defines how your team creates, names, merges, and deletes branches. Without one, codebases become chaotic — teams step on each other's work, releases break, and hotfixes take hours. With the right strategy, your workflow becomes predictable and scalable.
Common mistakes developers make with this:
Gitoryx: Gitoryx visualizes all your branches in a real-time commit graph. Create, switch, rename, and delete branches with a single click — no commands to memorize.
A Git branching strategy is a set of rules and conventions that define how branches are created, merged, and managed across a development team. Common strategies include GitFlow, GitHub Flow, and trunk-based development.
Before picking a strategy, understand the three most widely used models: GitFlow (structured, release-based), GitHub Flow (simple, continuous delivery), and trunk-based development (single main branch, short-lived branches).
For most small-to-medium teams shipping frequently, GitHub Flow or trunk-based development is simpler and faster than GitFlow.
Every strategy starts with protected long-lived branches. At minimum, you need a `main` (or `master`) branch that only receives tested, stable code.
# Rename master to main (modern convention)
git branch -m master main
git push origin main
git push origin --delete master
# Set main as default in your remote (GitHub/GitLab settings)Never commit directly to `main`. Every feature, bug fix, or improvement gets its own branch. Use a consistent naming convention.
# Create and switch to a feature branch
git checkout -b feature/user-authentication
# Or with a ticket number prefix:
git checkout -b feat/GIT-142-user-auth
# Push to remote and track:
git push -u origin feature/user-authenticationName branches with a type prefix: `feature/`, `fix/`, `hotfix/`, `chore/`. Include ticket IDs when your team uses a project tracker.
Long-lived feature branches diverge from `main` over time, making merges painful. Pull changes regularly.
# Option A: merge main into your branch
git checkout feature/user-authentication
git merge main
# Option B: rebase your branch onto main (cleaner history)
git rebase main
# Option C: pull with rebase
git pull --rebase origin mainNever rebase branches that are already shared with others — it rewrites history and causes conflicts for your teammates.
See this workflow in Gitoryx. See all branches at once in the visual commit graph — current, remote, stale, and diverged.
Free downloadWhen your feature is ready, open a pull request (PR) targeting `main`. Require at least one review before merging. This is the gate that keeps `main` stable.
Use a PR template to standardize descriptions. Include: what changed, why, and how to test.
After approval, merge the PR and immediately delete the feature branch — both locally and on the remote.
# After merging via PR, delete the remote branch
git push origin --delete feature/user-authentication
# Delete local branch
git branch -d feature/user-authentication
# If the branch wasn't merged and you want to force delete:
git branch -D feature/user-authenticationCritical production bugs need their own branch off `main` (or your release branch). Fix, test, merge directly to main, tag the release, then merge back to any develop/release branches.
# Create hotfix branch from main
git checkout main
git checkout -b hotfix/login-null-crash
# ... make fix ...
git add .
git commit -m "fix null check in login handler"
# Merge to main
git checkout main
git merge --no-ff hotfix/login-null-crash
git tag -a v1.2.1 -m "Hotfix: login null crash"
# Merge back to develop if using GitFlow
git checkout develop
git merge --no-ff hotfix/login-null-crashThe single most dangerous habit. One bad commit can break production for your entire team.
Fix: Protect your `main` branch in GitHub/GitLab settings. Require a PR and at least one approved review before any merge.
The longer a branch lives, the harder the merge becomes. Branches that stay open for weeks diverge massively from main.
Fix: Keep branches small and focused on a single change. Aim to merge within 1–3 days. If a feature is large, break it into smaller PRs.
Names like `test`, `fix`, `my-stuff`, or `john-branch` make it impossible to understand a branch's purpose at a glance.
Fix: Adopt a naming convention: `feature/`, `fix/`, `hotfix/`, `release/`, `chore/`. Enforce it via branch protection rules or a team agreement.
Over time, stale branches accumulate in the repo, cluttering the branch list and confusing new team members.
Fix: Enable auto-deletion of merged branches in GitHub/GitLab. Periodically run `git remote prune origin` to clean up local references.
Gitoryx — macOS, Windows & LinuxFor small teams (2–10 developers) shipping frequently, GitHub Flow is ideal: one `main` branch, short-lived feature branches, pull requests, and immediate merges. It is simple, fast, and avoids the overhead of GitFlow.
GitFlow uses multiple long-lived branches (`main`, `develop`, `release`, `hotfix`) and is best for versioned software with scheduled releases. GitHub Flow uses a single `main` branch with short-lived feature branches and is designed for continuous delivery.
Run `git branch -m old-name new-name` to rename a local branch. To update the remote, run `git push origin --delete old-name` then `git push -u origin new-name`.
A protected branch is a branch with rules enforced by your Git host (GitHub, GitLab, Bitbucket) that prevent direct pushes, require pull requests, and enforce status checks before merging. Always protect `main`.
Run `git branch` for local branches, `git branch -r` for remote branches, and `git branch -a` for both. Use `git log --oneline --graph --all` for a visual overview in the terminal.
Both work. Rebase (`git rebase main`) creates a cleaner linear history. Merge (`git merge main`) preserves context and is safer on shared branches. Many teams rebase locally before opening a PR, then use a merge commit for the PR itself.
Run `git push origin --delete branch-name`. In GitHub/GitLab, you can also delete branches directly from the pull request page after merging.
Trunk-based development means all developers commit to a single branch (`main` or `trunk`) multiple times per day. Feature flags hide incomplete features. It maximizes continuous integration speed but requires strong automated testing.
Everything in this tutorial is faster and clearer with a visual Git client. Gitoryx is free, runs natively on macOS, Windows, and Linux, and built for developers who want to move fast without breaking things.