Workflows
Team Collaboration
Master Git workflows for effective team collaboration, code review, and project management
Team Collaboration Workflows
Effective team collaboration with Git requires well-defined workflows, clear communication patterns, and robust processes that scale with your team size. This guide covers proven strategies for collaborative development.
Understanding Team Dynamics
Team Structure Impact on Workflows
Team Type | Size | Recommended Workflow | Key Considerations |
---|---|---|---|
Solo Developer | 1 | Simple feature branches | Focus on organization |
Small Team | 2-5 | GitHub Flow | Lightweight, flexible |
Medium Team | 6-15 | Git Flow or GitHub Flow | Clear role definition |
Large Team | 15+ | Git Flow with teams | Formal processes, automation |
Open Source | Variable | Fork-based workflow | External contributions |
Collaboration Challenges
# Common collaboration issues and solutions:
# 1. Merge conflicts - prevent with good branching strategy
git config merge.conflictstyle diff3 # Better conflict markers
# 2. Inconsistent commit messages - use conventional commits
# feat: add user authentication
# fix: resolve login timeout issue
# docs: update API documentation
# 3. Lost work - regular pushes and communication
git push origin feature-branch # Share work early and often
# 4. Unclear history - use meaningful branch names
feature/user-authentication
hotfix/security-vulnerability
chore/dependency-updates
Branching Strategies for Teams
GitHub Flow (Recommended for Most Teams)
Simple, continuous deployment focused workflow:
# 1. Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/add-user-profile
# 2. Work on feature with regular commits
git add .
git commit -m "feat: add user profile component"
git push -u origin feature/add-user-profile
# 3. Open Pull Request for review
# Use GitHub UI or CLI:
gh pr create --title "Add user profile functionality" --body "Implements user profile page with avatar upload"
# 4. Code review and approval
# Team reviews, requests changes, approves
# 5. Merge to main and deploy
# After approval, merge via GitHub
# Automatic deployment triggered
# 6. Clean up
git checkout main
git pull origin main
git branch -d feature/add-user-profile
git push origin --delete feature/add-user-profile
Git Flow (For Release-Based Projects)
Structured workflow with dedicated release branches:
# Initialize Git Flow
git flow init
# Create feature branch
git flow feature start user-authentication
# Work on feature...
git flow feature finish user-authentication
# Create release branch
git flow release start 1.2.0
# Bug fixes and release prep...
git flow release finish 1.2.0
# Hotfix for production
git flow hotfix start critical-security-fix
# Fix the issue...
git flow hotfix finish critical-security-fix
Trunk-Based Development
For teams with strong CI/CD and testing:
# Short-lived feature branches (< 2 days)
git checkout -b feature/quick-fix main
# Make small, focused changes
git commit -m "fix: resolve API timeout issue"
git push -u origin feature/quick-fix
# Immediate integration to main
# After quick review and CI passes
git checkout main
git merge feature/quick-fix
git push origin main
git branch -d feature/quick-fix
Code Review Best Practices
Pull Request Workflow
Creating Effective Pull Requests
# Before creating PR - self-review
git diff origin/main...feature-branch # Review all changes
git log --oneline origin/main..feature-branch # Review commits
# Rebase and clean up history if needed
git rebase -i origin/main
# Squash fixup commits, improve commit messages
# Push final version
git push --force-with-lease origin feature-branch
# Create PR with comprehensive description
gh pr create \
--title "feat: implement user notification system" \
--body "## Changes
- Add notification model and database migration
- Implement real-time notifications using WebSockets
- Add notification preferences UI
- Include comprehensive test coverage
## Testing
- Unit tests: npm test
- Integration tests: npm run test:integration
- Manual testing: test user notifications in dev environment
Closes #123"
PR Description Template
## Description
Brief summary of changes and motivation.
## Type of Change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
- [ ] Browser compatibility checked (if applicable)
## Screenshots (if applicable)
Add screenshots to help explain your changes.
## Checklist
- [ ] Code follows team style guidelines
- [ ] Self-review completed
- [ ] Code is properly commented
- [ ] Documentation updated
- [ ] No new warnings or errors introduced
Review Process Guidelines
For Reviewers
# Checkout PR locally for thorough review
gh pr checkout 123
# Review changes systematically
git log --oneline origin/main..HEAD # Review commit history
git diff origin/main...HEAD # Review all changes
git diff origin/main...HEAD --stat # See file change summary
# Test the changes
npm install # Install any new dependencies
npm test # Run test suite
npm start # Test application locally
# Review specific aspects:
# 1. Code quality and style
# 2. Test coverage
# 3. Security implications
# 4. Performance impact
# 5. Documentation accuracy
# 6. Breaking changes
Review Communication
# Effective review comments:
# ✅ Good feedback:
"Consider using a Map here instead of an array for O(1) lookups,
especially since this function is called frequently."
"This looks great! The error handling is comprehensive.
One small suggestion: consider adding a unit test for the edge case
where the API returns an empty response."
# ❌ Avoid:
"This is wrong."
"Bad code."
"Why did you do this?"
# Use GitHub's review features:
# - Request changes for blocking issues
# - Approve when ready to merge
# - Comment for non-blocking suggestions
Branch Management
Branch Naming Conventions
# Consistent naming patterns
feature/description-of-feature # New features
bugfix/issue-description # Bug fixes
hotfix/critical-security-fix # Production hotfixes
chore/dependency-updates # Maintenance tasks
docs/api-documentation-update # Documentation
test/add-integration-tests # Test improvements
# Include issue numbers when applicable
feature/123-user-authentication # Links to issue #123
bugfix/456-login-timeout # Links to issue #456
# Use lowercase and hyphens
feature/user-profile-page # ✅ Good
feature/User_Profile_Page # ❌ Avoid
feature/userProfilePage # ❌ Avoid
Branch Protection Rules
# Configure branch protection via GitHub API or UI
# Essential protection rules:
# 1. Require pull request reviews
# - At least 2 reviews for critical branches
# - Dismiss stale reviews when new commits pushed
# - Require review from code owners
# 2. Require status checks
# - All CI checks must pass
# - Security scans must pass
# - Code coverage thresholds met
# 3. Restrict pushes
# - No direct pushes to main/develop
# - Only administrators can override
# - Require linear history (optional)
# 4. Additional restrictions
# - Require signed commits
# - No force pushes
# - No deletions
Branch Cleanup
# Regular branch maintenance
# Remove merged branches locally
git branch --merged main | grep -v "\*\|main\|develop" | xargs -n 1 git branch -d
# Remove tracking branches for deleted remote branches
git remote prune origin
# List stale branches
git for-each-ref --format='%(refname:short) %(committerdate)' refs/heads | sort -k2
# Automated cleanup script
#!/bin/bash
# cleanup-branches.sh
git checkout main
git pull origin main
# Delete merged branches
merged_branches=$(git branch --merged main | grep -v "\*\|main\|develop")
if [ ! -z "$merged_branches" ]; then
echo "Deleting merged branches:"
echo "$merged_branches"
git branch --merged main | grep -v "\*\|main\|develop" | xargs -n 1 git branch -d
fi
# Prune remote tracking branches
git remote prune origin
Communication Patterns
Commit Message Standards
Conventional Commits Format
# Format: type(scope): description
#
# Types:
# feat: new feature
# fix: bug fix
# docs: documentation changes
# style: formatting, missing semicolons, etc.
# refactor: code change that neither fixes bug nor adds feature
# test: adding missing tests
# chore: maintain
# Examples:
git commit -m "feat(auth): add OAuth2 integration"
git commit -m "fix(api): resolve timeout issue in user endpoint"
git commit -m "docs(readme): add installation instructions"
git commit -m "test(user): add unit tests for user validation"
git commit -m "chore(deps): update dependencies to latest versions"
# Body and footer for complex changes:
git commit -m "feat(notification): add real-time notifications
- Implement WebSocket connection for live updates
- Add notification preferences in user settings
- Include push notification support for mobile
Closes #123
Reviewed-by: @teammate"
Commit Message Templates
# Set up commit message template
git config --global commit.template ~/.gitmessage
# ~/.gitmessage content:
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>
#
# Type: feat|fix|docs|style|refactor|test|chore
# Scope: component or file affected
# Subject: imperative, present tense, lowercase, no period
# Body: motivation for change and contrast with previous behavior
# Footer: breaking changes, issue references
Documentation Integration
# Link commits to issues and PRs
git commit -m "fix(login): resolve session timeout issue
Fixes timeout occurring after 1 hour of inactivity.
Updated session management to properly refresh tokens.
Closes #456
Related to #123"
# Reference in PR descriptions
# "This PR implements the feature requested in #789"
# "Fixes the bug reported in #456"
# "Part of the epic tracked in #123"
# Use GitHub's linking syntax:
# - Closes #123
# - Fixes #123
# - Resolves #123
# - Related to #123
# - See #123
Conflict Resolution
Preventing Conflicts
# Best practices to minimize conflicts:
# 1. Frequent integration
git fetch origin
git rebase origin/main # Regular rebase of feature branches
# 2. Small, focused changes
# Keep PRs small and focused on single features
# 3. Communication
# Coordinate with team on overlapping work
# 4. Consistent formatting
# Use automated formatting tools
# prettier, eslint, gofmt, black, etc.
# 5. Modular code structure
# Reduce likelihood of multiple people editing same files
Conflict Resolution Process
# When conflicts occur during merge/rebase:
# 1. Understand the conflict
git status # See conflicted files
git diff # View conflict markers
# 2. Resolve conflicts
# Edit files to resolve conflicts
# Remove conflict markers: <<<<<<<, =======, >>>>>>>
# 3. Test resolution
# Ensure code still works after resolution
npm test # Run tests
npm start # Test locally
# 4. Complete the process
git add resolved-file.js # Stage resolved files
git rebase --continue # Continue rebase
# OR
git commit # Complete merge
# 5. Communicate resolution
# Document complex resolutions in commit message
git commit -m "resolve: merge conflict in user authentication
Kept the new validation logic from feature branch
while preserving the error handling from main branch"
Advanced Conflict Resolution
# Use merge tools for complex conflicts
git config merge.tool vimdiff # Configure merge tool
git mergetool # Open merge tool
# Understand conflict context
git log --merge --left-right --oneline # See commits that conflict
git log --oneline main..feature-branch # See commits in feature branch
# Cherry-pick specific changes
git checkout main
git cherry-pick abc123 # Apply specific commit
git cherry-pick --no-commit abc123 # Apply without committing
# Resolve conflicts by choosing one side
git checkout --ours file.js # Keep "our" version (current branch)
git checkout --theirs file.js # Keep "their" version (incoming changes)
Release Management
Release Planning
# Version planning and tagging
# Follow Semantic Versioning (SemVer)
# MAJOR.MINOR.PATCH (e.g., 2.1.4)
# Major version: breaking changes
# Minor version: new features, backwards compatible
# Patch version: bug fixes, backwards compatible
# Create release branch
git checkout -b release/2.1.0 develop
# Bug fixes and release preparation
# Update version numbers, documentation
# Tag release
git tag -a v2.1.0 -m "Release version 2.1.0
New features:
- User profile management
- Advanced search functionality
- Email notifications
Bug fixes:
- Fixed login timeout issue
- Resolved data export bug
Breaking changes:
- API endpoint /users now requires authentication"
# Push release
git push origin main
git push origin v2.1.0
Release Notes Automation
# Generate release notes from commits
# Using conventional commits for automation
#!/bin/bash
# generate-release-notes.sh
LAST_TAG=$(git describe --tags --abbrev=0)
CURRENT_BRANCH=$(git branch --show-current)
echo "# Release Notes - $(date '+%Y-%m-%d')"
echo ""
echo "## Features"
git log $LAST_TAG..HEAD --oneline --grep="^feat" --format="- %s"
echo ""
echo "## Bug Fixes"
git log $LAST_TAG..HEAD --oneline --grep="^fix" --format="- %s"
echo ""
echo "## Documentation"
git log $LAST_TAG..HEAD --oneline --grep="^docs" --format="- %s"
echo ""
echo "## Contributors"
git log $LAST_TAG..HEAD --format="- %an" | sort -u
Team Workflows
Daily Development Flow
# Morning routine
git checkout main
git pull origin main # Get latest changes
git branch -d merged-branches # Clean up old branches
# Start new work
git checkout -b feature/new-feature
# Work, commit, push regularly
git add .
git commit -m "feat: implement new feature"
git push -u origin feature/new-feature
# Evening routine
git push origin feature/new-feature # Backup work
# Open PR if ready for review
gh pr create --draft # Draft PR for early feedback
Code Review Rotation
# Implement review rotation system
# .github/CODEOWNERS
* @team-lead @senior-dev1
*.js @frontend-team
*.py @backend-team
*.sql @database-team
/docs/ @tech-writer @team-lead
# Review assignment strategies:
# 1. Round-robin: rotate reviewers
# 2. Expertise-based: assign domain experts
# 3. Load-balanced: distribute review load evenly
# 4. Mentoring: pair junior with senior developers
Integration Patterns
# Continuous Integration workflow
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [ main ]
push:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node
uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm ci
- run: npm test
- run: npm run lint
- run: npm run type-check
- run: npm run security-audit
Scaling Team Workflows
Large Team Considerations
# Multiple team coordination
# Use team-specific branches
git checkout -b team-frontend/user-interface
git checkout -b team-backend/api-refactor
git checkout -b team-mobile/notifications
# Cross-team integration points
# Regular integration branches
git checkout -b integration/sprint-12
git merge team-frontend/user-interface
git merge team-backend/api-refactor
# Resolve integration issues
# Team-specific workflows
# Frontend team: focus on UI/UX branches
# Backend team: API and service branches
# DevOps team: infrastructure and deployment
# QA team: testing and automation branches
Automation and Tooling
# Automated quality gates
# Pre-commit hooks
#!/bin/sh
# .git/hooks/pre-commit
npm run lint
npm run test:unit
npm run type-check
# Automated PR checks
# - Code coverage threshold
# - Performance regression tests
# - Security vulnerability scanning
# - Documentation updates
# Automated releases
# - Version bumping
# - Changelog generation
# - Tag creation
# - Release notes
# - Deployment triggers
Best Practices Summary
Team Collaboration Checklist
✅ Do:
- Establish clear branching strategy
- Use meaningful commit messages
- Review code thoroughly
- Communicate changes early
- Keep PRs small and focused
- Test changes before requesting review
- Document decisions and processes
- Clean up branches regularly
❌ Don't:
- Push directly to main branch
- Skip code reviews for "small" changes
- Let branches live too long
- Ignore merge conflicts
- Use generic commit messages
- Review your own PRs
- Merge without proper testing
- Keep stale branches around
Workflow Selection Guide
Situation | Recommended Workflow |
---|---|
Small team, frequent releases | GitHub Flow |
Scheduled releases, complex product | Git Flow |
Continuous deployment | Trunk-based Development |
Open source project | Fork-based workflow |
Enterprise with compliance | Git Flow + additional gates |
Next Steps
🤝 Congratulations! You now understand effective team collaboration with Git.
Enhance your team workflow:
- Explore Git Flow - Structured release management
- Learn GitHub Flow - Streamlined continuous deployment
- Set up CI/CD Integration - Automated quality gates
Team Process Maturity
- Establish branching strategy
- Implement code review process
- Set up automated testing
- Create documentation standards
- Define release process
- Implement monitoring and metrics
- Regular process retrospectives
- Team training and knowledge sharing