Which Git workflow should I use for a small team?
GitHub Flow is the best choice for small teams (2-10 developers). It is simple: create a feature branch from main, make changes, open a pull request, get a review, and merge. There is no develop branch or release branches to manage. Most startups and small teams at companies like GitHub and Shopify use this workflow.
What is the difference between GitHub Flow and Git Flow?
GitHub Flow has one main branch and feature branches, and that is it. Git Flow adds develop, release, and hotfix branches on top of main. GitHub Flow is simpler and works well with continuous deployment. Git Flow is better when you need to maintain multiple versions or have scheduled releases with QA cycles.
When should I use trunk-based development?
Use trunk-based development when your team has strong CI/CD, good test coverage, and wants to deploy frequently (multiple times a day). Engineers commit directly to main or use very short-lived branches (1-2 days max). Companies like Google, Meta, and Netflix use this approach at scale with feature flags to control rollout.
How do I handle hotfixes in production?
Branch from main (or your production tag), fix the bug, test it, merge to main, and deploy. If you use Git Flow, also merge the hotfix into develop. Always tag the hotfix release (e.g., v1.2.1). The key is to branch from the production state, not from develop, so you only ship the fix without unfinished features.
Should I squash merge or regular merge pull requests?
Squash merge collapses all PR commits into one clean commit on main, which is great for keeping main history readable. Regular merge preserves full commit history, which is useful when individual commits are meaningful. Most teams use squash merge for feature branches and regular merge for release branches. GitHub, GitLab, and Bitbucket all support both options.