GitHub Flow
Overview
GitHub Flow is a lightweight, branch-based workflow for software development designed around continuous delivery and deployment. It's optimized for collaborative, cloud-based, and fast-paced development, especially for web apps and APIs.
GitHub Flow was introduced by GitHub to simplify the process of contributing code and deploying changes continuously.
General Approach of GitHub Flow
1. Create a branch
Create a new branch from main for each feature or fix:
git checkout -b feature/cool-new-feature
2. Make changes locally and push
Commit work to your feature branch, and push it to GitHub:
git push origin feature/cool-new-feature
3. Open a Pull Request (PR)
Once you're ready to share or get feedback, open a PR to main. PRs serve as collaboration points:
- Code review
- CI checks
- Discussions
4. Discuss and review code
Collaborators review your code and suggest changes before merging.
5. Deploy from the branch (optional)
Optionally deploy the branch to a staging environment to test it before merging.
6. Merge after approval
Once reviewed and tested, the branch is merged into main.
This should trigger a deployment (in CD-enabled environments):
git checkout main
git pull origin main
git merge feature/cool-new-feature
7. Deploy to production
Deployment to production can be automatic from main, or manual depending on your setup.
Positives of GitHub Flow
- Simplicity – Easy to understand and follow.
- CI/CD Friendly – Designed for environments where deployments are frequent and automated.
- Pull Request Centric – Code reviews are encouraged and easy to manage.
- Good for SaaS/web apps – Especially where "deploy often" is the norm.
- Encourages small, testable changes – Reduces merge conflicts and regressions.
Negatives of GitHub Flow
- No long-running environments – Not ideal for teams needing dev, test, staging, and production branches with different timelines.
- Limited support for parallel release tracks – Lacks the structure for supporting multiple versions or hotfixes on older releases.
- Assumes you can deploy from
mainanytime – Not suitable if you can't safely or frequently deploy. - Can get chaotic with many contributors – Without discipline, frequent merges to
maincan destabilise it
Comparison: GitHub Flow vs GitFlow
| Feature | GitHub Flow | GitFlow |
|---|---|---|
| Simplicity | Very simple | More complex, with many branch types |
| Primary branches | main |
main, develop, feature/*, release/*, hotfix/* |
| Suitable for | Continuous delivery & web development | Release-driven development and versioning |
| Release branches | Not used | Explicit release/* branches |
| Hotfix support | Done from main |
hotfix/* branches from main |
| Environment support | One live version at a time | Supports multiple parallel versions/releases |
| Deployment pipeline | Automated from main |
Manual, often from release branches |
| Merge strategy | Always merge back to main |
Merge to develop, then to main on release |
Example: GitHub Flow in Action
Scenario: Adding a login feature
1. Branch off
git checkout -b feature/login
2. Develop and commit locally
git commit -am "Add basic login form and validation"
git push origin feature/login`
3. Open a Pull Request on GitHub
Target: main
Reviewers: backend team
4. Get feedback, push updates if needed
git commit -am "Update password strength validation" git push