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-updatesBranching 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-profileGit 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-fixTrunk-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-fixCode 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 introducedReview 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 changesReview 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 suggestionsBranch 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 # ❌ AvoidBranch 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 deletionsBranch 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 originCommunication 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 referencesDocumentation 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 #123Conflict 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 filesConflict 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.0Release 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 -uTeam 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 feedbackCode 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 developersIntegration 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-auditScaling 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 branchesAutomation 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 triggersBest 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