GitHub Flow
GitHub Flow is a lightweight, branch-based workflow designed for teams and projects that deploy regularly. It's simpler than Git Flow and focuses on continuous delivery, making it ideal for web applications and SaaS products.
What is GitHub Flow?
GitHub Flow is a streamlined workflow created by GitHub that emphasizes simplicity and continuous deployment. It uses only one long-lived branch (main) and short-lived feature branches.
Philosophy: GitHub Flow is based on the principle that anything in the main branch is always deployable. This simplicity enables rapid iteration and continuous delivery.
The GitHub Flow Process
GitHub Flow consists of six simple steps:
Step 1: Create a Branch
Branch off from main for any new work
Step 2: Add Commits
Make changes and commit regularly with clear messages
Step 3: Open a Pull Request
Start discussion about your changes
Step 4: Discuss and Review
Team reviews and discusses the code
Step 5: Deploy and Test
Deploy to staging/production for testing (optional)
Step 6: Merge to Main
After approval, merge and deploy to production
Visualizing GitHub Flow
The workflow is straightforward:
main o---o---o---o---o---o
\ / \
feature o-----o o---o
\ \
another-feature o---o
Step 1: Create a Branch
Always branch from main for new work:
# Update main to latest
git checkout main
git pull origin main
# Create a descriptive branch
git checkout -b add-user-profile
# Or in one command:
git checkout -b add-user-profile origin/main
# Push branch to remote immediately
git push -u origin add-user-profile
Branch Naming: Use descriptive names that explain what the branch does: add-login-form, fix-navbar-bug, update-readme
Step 2: Add Commits
Make changes and commit frequently:
# Make changes to files
# ...
# Stage and commit
git add .
git commit -m "Add user profile page structure"
# Continue working
# ...
git commit -m "Add profile image upload"
git commit -m "Add profile edit functionality"
# Push commits to remote
git push origin add-user-profile
Commit Best Practices:
✓ Commit often with focused changes
✓ Write clear, descriptive commit messages
✓ Push commits regularly to backup your work
✓ Each commit should represent a logical unit
✓ Use present tense: "Add feature" not "Added feature"
Step 3: Open a Pull Request
Create a PR as soon as you have something to discuss:
# On GitHub:
1. Navigate to your repository
2. Click "Pull requests" → "New pull request"
3. Select your branch to compare with main
4. Add title and description
5. Click "Create pull request"
# Or use GitHub CLI:
gh pr create --title "Add user profile feature" \
--body "Implements user profile with image upload"
Early PRs: Don't wait until work is complete! Create a draft PR early to get feedback and show progress. You can convert it to ready-for-review later.
Step 4: Discuss and Review
Collaborate through code review:
As Author:
- Respond to all comments
- Make requested changes
- Push new commits to update PR
- Request re-review after changes
- Be open to feedback
As Reviewer:
- Review code thoroughly
- Ask questions for clarity
- Suggest improvements
- Approve when satisfied
- Be constructive and respectful
Making changes based on review:
# Address review comments
git checkout add-user-profile
# Make changes
# ...
git commit -m "Address review feedback: improve validation"
git push origin add-user-profile
# PR automatically updates with new commits
Step 5: Deploy and Test (Optional)
Many teams deploy branch to staging before merging:
# Deploy branch to staging environment
git checkout add-user-profile
git push staging add-user-profile
# Or use deployment tools
# Deploy to preview environment
# Test the changes live
# If issues found, fix and push
git commit -m "Fix styling issue"
git push origin add-user-profile
Preview Deployments: Tools like Netlify, Vercel, and Heroku can automatically deploy PR branches to preview URLs for testing.
Step 6: Merge to Main
Once approved and tested, merge to main:
# On GitHub (recommended):
1. Click "Merge pull request"
2. Choose merge strategy (squash, merge, rebase)
3. Click "Confirm merge"
4. Delete branch (GitHub prompts automatically)
# Or from command line:
git checkout main
git pull origin main
git merge add-user-profile
git push origin main
git branch -d add-user-profile
Branch Protection Rules
Enforce GitHub Flow best practices:
# On GitHub: Settings → Branches → Branch protection rules
Recommended Rules for Main:
✓ Require pull request before merging
✓ Require approvals (at least 1-2 reviewers)
✓ Require status checks to pass (CI tests)
✓ Require branches be up to date before merging
✓ Require conversation resolution before merging
✓ Do not allow bypassing these rules
Optional Rules:
- Require code owner review
- Require signed commits
- Restrict who can push to main
Critical: Never commit directly to main. Always use pull requests, even for small changes. This ensures code review and maintains deployment safety.
Continuous Deployment
Automate deployment when merging to main:
# .github/workflows/deploy.yml
name: Deploy to Production
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run build
- name: Deploy to production
run: npm run deploy
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
When to Use GitHub Flow
GitHub Flow is ideal for certain scenarios:
✓ Perfect For:
- Web applications
- SaaS products
- APIs and microservices
- Continuous deployment environments
- Small to medium teams
- Projects with frequent deploys
- Open source projects
✗ Consider Alternatives For:
- Mobile apps (App Store approval delays)
- Desktop software (scheduled releases)
- Projects with long QA cycles
- Multiple production versions
- Projects requiring release branches
GitHub Flow vs Git Flow
Understanding the key differences:
GitHub Flow:
+ Simple and easy to learn
+ One main branch (main)
+ Fast, continuous deployment
+ Minimal overhead
+ Great for web apps
- No structured release process
- Not ideal for multiple versions
Git Flow:
+ Structured release management
+ Multiple long-lived branches
+ Clear version control
+ Good for scheduled releases
- More complex
- Slower deployment cycle
- Higher overhead
Best Practices for GitHub Flow
✓ Keep main branch always deployable
✓ Create branches for all changes
✓ Use descriptive branch names
✓ Commit and push frequently
✓ Open pull requests early
✓ Write detailed PR descriptions
✓ Review code thoroughly
✓ Use status checks (CI/CD)
✓ Test before merging
✓ Deploy immediately after merge
✓ Delete merged branches
✓ Keep branches short-lived (hours/days, not weeks)
Handling Hotfixes
Quick fixes follow the same process:
# Hotfixes use the same workflow
git checkout main
git pull origin main
git checkout -b fix-critical-security-bug
# Fix the issue
git commit -m "Fix security vulnerability in auth"
git push -u origin fix-critical-security-bug
# Create PR (can mark as urgent)
gh pr create --title "HOTFIX: Security vulnerability" \
--body "Critical security fix" \
--label "urgent"
# Fast review and merge
# Deploy automatically to production
Speed vs Safety: Even for hotfixes, maintain the PR process. Quick review is fine, but never skip code review entirely - another pair of eyes can catch issues.
Managing Multiple Environments
Deploy strategy for different environments:
Common Setup:
Development:
- Auto-deploy PR branches to preview URLs
- Each PR gets its own environment
Staging:
- Deploy main branch automatically
- Pre-production testing environment
- Mirror of production
Production:
- Deploy main branch after staging tests pass
- Automatic or manual trigger
- Monitor for issues
Rollback Strategy
Handle issues after deployment:
# Option 1: Revert the merge commit
git checkout main
git pull origin main
git revert -m 1 HEAD # Revert the merge
git push origin main
# This creates a new commit that undoes changes
# Option 2: Create a fix-forward branch
git checkout main
git checkout -b fix-deployment-issue
# Fix the issue
git commit -m "Fix deployment issue"
# Create PR and merge quickly
# Option 3: Use deployment tools
# Many platforms allow instant rollback to previous version
# Example: Heroku, Vercel, AWS, etc.
Team Collaboration Tips
Communication:
- Use PR descriptions to explain context
- Link related issues and PRs
- Add screenshots for UI changes
- Mention team members for input
Code Review:
- Review within 24 hours
- Be specific in feedback
- Suggest, don't demand
- Approve when satisfied
Branch Management:
- Keep branches up-to-date with main
- Delete after merging
- Close stale PRs
- One branch per feature/fix
Practical Exercise:
Task: Practice complete GitHub Flow workflow
- Create a new repository on GitHub
- Set up branch protection rules for main
- Create a feature branch:
git checkout -b add-homepage
- Add an index.html file and commit
- Push branch:
git push -u origin add-homepage
- Create a Pull Request on GitHub
- Request review from a teammate (or yourself for practice)
- Make a change based on "review feedback"
- Merge the PR using "Squash and merge"
- Delete the feature branch
- Set up GitHub Actions to auto-deploy on merge to main
Expected Outcome: Complete understanding of GitHub Flow from branch creation to deployment.
Common Mistakes to Avoid
Mistake: Committing directly to main
Solution: Use branch protection rules to prevent this
Mistake: Long-lived branches
Solution: Keep branches small and merge frequently
Mistake: Skipping code review
Solution: Require PR approvals in branch protection
Mistake: Not testing before merge
Solution: Use CI/CD and status checks
Mistake: Merging broken code
Solution: Ensure all tests pass before merging
Mistake: Poor PR descriptions
Solution: Use PR templates and explain changes clearly
Tools that Support GitHub Flow
CI/CD:
- GitHub Actions
- CircleCI
- Travis CI
- Jenkins
Deployment:
- Vercel
- Netlify
- Heroku
- AWS Amplify
Code Review:
- GitHub Code Review
- Review apps (preview deployments)
- Automated checks (linters, tests)
Project Management:
- GitHub Projects
- GitHub Issues
- Integration with Jira, Linear, etc.
Summary
In this lesson, you learned:
- GitHub Flow is a simple, branch-based workflow
- Six steps: branch, commit, PR, review, deploy, merge
- Only one long-lived branch (main) is used
- Main branch is always deployable
- Pull requests are central to the workflow
- Branch protection rules enforce best practices
- Continuous deployment happens on every merge
- Perfect for web apps and continuous delivery
- Simpler than Git Flow but requires discipline
- Rollback strategies handle deployment issues
Next Up: In the next lesson, we'll explore Trunk-Based Development, an even simpler workflow for teams that want extremely fast iteration!