šæ Why Git Workflows Matter?
- Team Coordination: Everyone follows same process
- Code Quality: Review before merging
- Release Management: Organized deployments
- Bug Fixes: Hotfix without disrupting development
- Feature Development: Isolated work on features
- Rollback: Easy to revert changes
š Popular Git Workflows
1. Git Flow
Comprehensive branching model for projects with scheduled releases.
Branch Structure
- main: Production-ready code
- develop: Integration branch for features
- feature/*: New features
- release/*: Release preparation
- hotfix/*: Emergency production fixes
# Start new feature git checkout develop git checkout -b feature/user-authentication # Work on feature git add . git commit -m "Add login functionality" # Finish feature git checkout develop git merge feature/user-authentication git branch -d feature/user-authentication # Create release git checkout develop git checkout -b release/1.0.0 # Bug fixes only on release branch # Finish release git checkout main git merge release/1.0.0 git tag -a v1.0.0 -m "Version 1.0.0" git checkout develop git merge release/1.0.0 git branch -d release/1.0.0 # Hotfix git checkout main git checkout -b hotfix/critical-bug # Fix the bug git checkout main git merge hotfix/critical-bug git tag -a v1.0.1 -m "Hotfix 1.0.1" git checkout develop git merge hotfix/critical-bug git branch -d hotfix/critical-bug
ā Best For
- ⢠Large teams
- ⢠Scheduled releases
- ⢠Multiple versions in production
- ⢠Enterprise projects
2. GitHub Flow
Simplified workflow for continuous deployment. Single main branch with feature branches.
# Create feature branch git checkout main git pull origin main git checkout -b feature/add-dark-mode # Make changes git add . git commit -m "Implement dark mode toggle" # Push to remote git push origin feature/add-dark-mode # Create Pull Request on GitHub # After review and approval, merge to main # Delete branch git checkout main git pull origin main git branch -d feature/add-dark-mode # Deploy automatically from main
ā Best For
- ⢠Small to medium teams
- ⢠Continuous deployment
- ⢠Web applications
- ⢠Fast iteration
3. Trunk-Based Development
Developers work on short-lived branches or directly on main. Requires strong CI/CD.
# Short-lived branch (1-2 days max) git checkout main git pull origin main git checkout -b quick-fix # Make small change git add . git commit -m "Fix button alignment" # Push and merge quickly git push origin quick-fix # Create PR, get quick review, merge # Or commit directly to main (with CI/CD safety net) git checkout main git pull origin main # Make change git add . git commit -m "Update API endpoint" git push origin main # CI/CD runs tests automatically
ā Best For
- ⢠High-performing teams
- ⢠Strong CI/CD pipeline
- ⢠Feature flags for incomplete features
- ⢠Continuous integration culture
š Commit Best Practices
Commit Message Format
# Conventional Commits <type>(<scope>): <subject> <body> <footer> # Types: feat: New feature fix: Bug fix docs: Documentation changes style: Code style (formatting, no logic change) refactor: Code refactoring test: Adding tests chore: Build process, dependencies # Examples: feat(auth): add JWT authentication fix(api): resolve null pointer exception docs(readme): update installation instructions refactor(utils): simplify date formatting logic # Good commit message feat(user-profile): add avatar upload functionality - Implement file upload with validation - Add image compression - Update user model with avatar field - Add tests for upload endpoint Closes #123 # Bad commit messages ā "fixed stuff" ā "update" ā "changes" ā "wip"
Commit Guidelines
- Atomic commits: One logical change per commit
- Descriptive messages: Explain what and why, not how
- Present tense: "Add feature" not "Added feature"
- Imperative mood: "Fix bug" not "Fixes bug"
- Reference issues: "Closes #123" or "Fixes #456"
- Keep it short: Subject line under 50 characters
š Pull Request Best Practices
PR Checklist
- ā Clear title and description
- ā Link to related issue
- ā Small, focused changes (under 400 lines)
- ā Tests added/updated
- ā Documentation updated
- ā No merge conflicts
- ā CI/CD passing
- ā Self-review completed
- ā Screenshots for UI changes
PR Template
## Description Brief description of changes ## Type of Change - [ ] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation update ## Related Issue Closes #123 ## Changes Made - Added user authentication - Implemented JWT tokens - Updated API endpoints ## Testing - [ ] Unit tests pass - [ ] Integration tests pass - [ ] Manual testing completed ## Screenshots (if applicable) [Add screenshots here] ## Checklist - [ ] Code follows style guidelines - [ ] Self-review completed - [ ] Comments added for complex code - [ ] Documentation updated - [ ] No new warnings
š ļø Essential Git Commands
# Branch Management
git branch # List branches
git branch feature-name # Create branch
git checkout feature-name # Switch branch
git checkout -b feature-name # Create and switch
git branch -d feature-name # Delete branch
git branch -D feature-name # Force delete
# Syncing
git fetch origin # Fetch changes
git pull origin main # Pull and merge
git push origin feature-name # Push branch
git push -u origin feature # Push and set upstream
# Merging
git merge feature-name # Merge branch
git merge --no-ff feature # Merge with merge commit
git rebase main # Rebase on main
# Stashing
git stash # Stash changes
git stash pop # Apply and remove stash
git stash list # List stashes
git stash apply stash@{0} # Apply specific stash
# Undoing Changes
git reset HEAD~1 # Undo last commit (keep changes)
git reset --hard HEAD~1 # Undo last commit (discard changes)
git revert commit-hash # Create new commit that undoes
git checkout -- file.txt # Discard file changes
# History
git log # View commit history
git log --oneline # Compact history
git log --graph --all # Visual branch history
git show commit-hash # Show commit details
# Tagging
git tag v1.0.0 # Create tag
git tag -a v1.0.0 -m "msg" # Annotated tag
git push origin v1.0.0 # Push tag
git push origin --tags # Push all tagsā ļø Common Mistakes to Avoid
- Committing to main directly: Always use feature branches
- Large commits: Break into smaller, logical commits
- Poor commit messages: Be descriptive and clear
- Not pulling before pushing: Always sync first
- Committing secrets: Use .gitignore, environment variables
- Force pushing to shared branches: Avoid git push -f on main
- Long-lived branches: Merge frequently to avoid conflicts
- Not reviewing own code: Self-review before PR
š Security Best Practices
- ā Never commit API keys, passwords, tokens
- ā Use .gitignore for sensitive files
- ā Review .env files before committing
- ā Use git-secrets or similar tools
- ā Enable branch protection rules
- ā Require code reviews
- ā Sign commits with GPG
- ā Use SSH keys for authentication
š Workflow Comparison
| Feature | Git Flow | GitHub Flow | Trunk-Based |
|---|---|---|---|
| Complexity | High | Low | Medium |
| Branch Lifetime | Long | Medium | Short (1-2 days) |
| Release Cycle | Scheduled | Continuous | Continuous |
| Team Size | Large | Small-Medium | Any (with CI/CD) |
| CI/CD Required | Optional | Recommended | Essential |
šÆ Conclusion
Choose a Git workflow that fits your team size, release cycle, and deployment strategy. GitHub Flow works well for most modern web projects with continuous deployment. Git Flow is better for scheduled releases and enterprise projects. Trunk-Based Development requires strong CI/CD but enables fastest delivery.
Whatever workflow you choose, consistency is key. Document your process, train your team, and enforce it through branch protection rules and code reviews.
š Automate Your Workflow
Set up CI/CD pipelines to automate testing and deployment. Learn how to build automated workflows.
CI/CD Guide ā