Overview of popular branching strategies and best practices for working with Git in a team.
"Who overwrote my changes?" "Why is the old code on production?" "Merge conflict - 47 files" - sound familiar? Without established Git workflow rules, a team of 5 developers can generate more chaos than a startup during a pivot.
We've worked with teams where the lack of workflow cost days of work - overwritten changes, lost features, hotfixes that never made it to develop. Here's how to avoid that.
Three philosophies: Git Flow vs GitHub Flow vs Trunk-Based
There's no "best" workflow - there's one that fits your team and release cycle.
Git Flow (Vincent Driessen)
- Branches: main, develop, feature/*, release/*, hotfix/*
- For whom: products with planned versions (v1.0, v2.0)
- Pros: clean history, easy hotfixes, parallel releases
- Cons: complicated for small teams, long feature branches
GitHub Flow
- Branches: main + feature branches
- For whom: continuous deployment, SaaS, small teams
- Pros: simplicity, fast iterations, easy onboarding
- Cons: harder to manage multiple versions
Trunk-Based Development is the "elite performers" approach from the DORA report - teams with the highest deployment frequency and lowest mean time to recovery. But it requires: solid CI/CD, automated tests, feature flags, and mature code review culture.
How to implement workflow in your team?
Choose workflow and document it
Team of 2-5 people, CI/CD? GitHub Flow. Planned releases, multiple versions? Git Flow. Write the decision in README or wiki.
Configure branch protection
Block push to main. Require PR with minimum 1 review. Enable required CI checks before merge.
Establish naming conventions
feature/ABC-123-user-login, bugfix/ABC-456-null-pointer, hotfix/v1.2.1-security-patch. Link to tickets.
Implement conventional commits
feat:, fix:, docs:, refactor:, test:, chore: - automatic changelogs, semantic versioning.
Workflow retrospective
Monthly: is the workflow working? Are there bottlenecks? Is code review taking too long?
5 practices that will change your repo quality
Atomic commits
One commit = one logical change. Not "WIP", not "fixes", not "changes". Each commit should compile and pass tests.
Rebase before merge
git pull --rebase instead of git pull. Linear history instead of "spaghetti graph". Easier git bisect, cleaner git log.
Squash when merging to main
Feature branch can have 20 WIP commits - but main gets one clean commit with a full description of the change.
Pre-commit hooks
Husky + lint-staged: automatic linting, formatting, type checking BEFORE commit. Zero "fix linting" commits.
Meaningful PR descriptions
What changes? Why? How to test? Screenshots for UI changes. PR template in repo is a must-have.
Git commands you must know
# Interactive rebase - clean up commits before PR
git rebase -i HEAD~5
# Stash with name - don't lose WIP
git stash push -m "feature X work in progress"
# Cherry-pick - move commit between branches
git cherry-pick abc123
# Bisect - find the commit that introduced a bug
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Reflog - recover "lost" commits
git reflog
git checkout HEAD@{2}
Metrics of a healthy repo
Google published research: PRs over 400 lines have drastically lower review quality. Large PR = surface-level review = bugs in production.
Chaos in your repo? We'll help organize it
Workflow audit, branch protection implementation, CI/CD configuration, team training - we'll build a process that works.