A well-defined Git workflow is essential for team productivity. The wrong approach leads to merge conflicts, broken builds, and developer frustration. Let's explore the strategies that keep teams shipping quality code consistently.
Choosing Your Branching Strategy
The two dominant strategies are GitFlow and Trunk-Based Development. Your choice depends on team size, release frequency, and deployment capabilities.
text
# Trunk-Based Development (Recommended for most teams)
main ──●──●──●──●──●──●──●──●── (always deployable)
\ / \ / \ /
feature ●─● ●─● ●─● (short-lived, < 2 days)
# GitFlow (For scheduled releases)
main ────────●────────────●──── (production)
/ /
release ────●────────────● (staging)
/ / /
develop ──●──●──●──●──●──●──●────── (integration)
\ / \ /
feature ●─● ●─● (feature work)Conventional Commits
Structured commit messages make history readable, enable automated changelogs, and integrate with semantic versioning tools.
text
# Format: <type>(<scope>): <description>
# Types:
feat: New feature (MINOR version bump)
fix: Bug fix (PATCH version bump)
docs: Documentation only
style: Code style (formatting, semicolons)
refactor: Code change that neither fixes nor adds
perf: Performance improvement
test: Adding or updating tests
chore: Build process or auxiliary tools
# Examples:
feat(auth): add OAuth2 login support
fix(api): handle null response from user endpoint
docs(readme): update installation instructions
refactor(utils): extract date formatting to helper
# Breaking changes (MAJOR version bump):
feat(api)!: change response format for user endpoint
BREAKING CHANGE: response.user is now response.data.userPull Request Best Practices
- Keep PRs small - under 400 lines of changes when possible
- Write descriptive PR titles following conventional commit format
- Include context: what, why, and how to test
- Self-review before requesting reviews from others
- Respond to feedback within 24 hours
- Squash commits on merge for clean history
- Delete branches after merging
markdown
## PR Template
### What
Brief description of the changes
### Why
Context and reasoning behind the changes
### How to Test
1. Step-by-step testing instructions
2. Expected behavior
### Screenshots
If applicable
### Checklist
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No console errors
- [ ] Tested on mobile
Handling Merge Conflicts
Merge conflicts are inevitable but manageable. The key is to rebase frequently and communicate with your team about overlapping work.
bash
# Stay up to date with main (do this daily)
git fetch origin
git rebase origin/main
# If conflicts occur:
# 1. Resolve conflicts in your editor
# 2. Stage resolved files
git add <resolved-files>
# 3. Continue rebase
git rebase --continue
# If things go wrong, abort and start over
git rebase --abort
# Force push after rebasing (only on your branches!)
git push --force-with-leaseUseful Git Commands
bash
# Interactive rebase to clean up commits
git rebase -i HEAD~5
# Stash changes with a message
git stash push -m "WIP: feature description"
# Create a branch from a specific commit
git checkout -b feature/new-thing abc123
# Cherry-pick a commit from another branch
git cherry-pick abc123
# Undo last commit but keep changes
git reset --soft HEAD~1
# See what changed in a file over time
git log -p -- path/to/file
# Find who changed a specific line
git blame -L 10,20 path/to/file< 2 daysMax branch age
< 400Lines per PR
24hReview response time
0Direct main commits
