Git excels at enabling collaboration between developers. This guide covers essential collaboration patterns and best practices for working effectively with teams.
Roles and Responsibilities
Git users can be broadly grouped into categories based on their collaboration needs:
Individual Developer (Standalone)
A standalone developer works alone in a single repository:
git init # Create a new repository
git add . # Stage changes
git commit -m "message" # Record changes
git log # View history
git branch feature-x # Create branches
git merge feature-x # Merge branches
git tag v1.0 # Mark releases
Individual Developer (Participant)
A participant in a group project needs additional commands:
git clone <url> # Get the project
git pull # Fetch and merge updates
git push # Share your changes
git fetch # Get updates without merging
git format-patch # Create patch files
git send-email # Email patches
Integrator
Integrators receive, review, and integrate changes from others:
git am # Apply emailed patches
git pull <url> <branch> # Merge contributor branches
git revert # Undo problematic commits
git format-patch # Suggest alternatives
git push # Publish integrated changes
Repository Administrator
Administrators manage repository infrastructure:
- Configure
git-daemon for anonymous access
- Set up
git-shell for restricted access
- Configure
git-http-backend for HTTP(S) access
- Install and configure hooks for automation
- Manage permissions and access control
Setting Up for Collaboration
Configuring Your Identity
Before collaborating, configure your identity:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Use your real name in user.name - this is what appears in commits. The user.email should match your account on your Git hosting service for proper attribution.
Cloning a Repository
Start collaborating by cloning an existing repository:
Clone the repository
git clone https://github.com/org/project.git
cd project
Verify remote configuration
git remote -v
# origin https://github.com/org/project.git (fetch)
# origin https://github.com/org/project.git (push)
Check current branch
git branch -a
# * main
# remotes/origin/HEAD -> origin/main
# remotes/origin/main
Basic Collaboration Workflow
Daily Development Cycle
Start with latest changes
git switch main
git pull origin main
Create a feature branch
git switch -c feature/new-login
Make changes and commit
# Edit files
git add src/auth.js tests/auth.test.js
git commit -m "Add OAuth2 login support"
Keep your branch updated
# Periodically sync with main
git fetch origin
git merge origin/main
# Or: git rebase origin/main
Push your changes
git push -u origin feature/new-login
Create a pull request
Use your Git hosting service (GitHub, GitLab, Bitbucket) to create a pull request from your branch to main.
Reviewing Changes
Before submitting changes for review:
# Review your changes
git diff main...feature/new-login
# Check commit history
git log main..feature/new-login
# Ensure tests pass
git stash push --keep-index
# Run tests
git stash pop
Working with Remote Repositories
Understanding Remotes
Remotes are named references to other repositories:
# List remotes
git remote -v
# Add a new remote
git remote add upstream https://github.com/original/project.git
# Rename a remote
git remote rename origin my-fork
# Remove a remote
git remote remove old-remote
# Change remote URL
git remote set-url origin https://github.com/new/url.git
Fetching and Pulling
Fetch downloads changes without modifying your working tree:
# Fetch from all remotes
git fetch --all
# Fetch from specific remote
git fetch origin
# Fetch specific branch
git fetch origin main
# View fetched changes
git log HEAD..origin/main
git diff HEAD...origin/main
# Pull from tracking branch
git pull
# Pull from specific remote and branch
git pull origin main
# Pull with rebase instead of merge
git pull --rebase origin main
Only use git pull when you actually want to merge. If you just want to see what others have done, use git fetch instead.
Pushing Changes
# Push current branch to origin
git push
# Push and set upstream tracking
git push -u origin feature-branch
# Push all branches
git push --all origin
# Push tags
git push --tags
git push --follow-tags # Only push annotated tags
# Force push (use with caution)
git push --force-with-lease origin branch
Never force push to shared branches like main without team agreement. Use --force-with-lease instead of --force to avoid overwriting others’ work.
Collaboration Patterns
Centralized Workflow
Similar to CVS/SVN, everyone pushes to a single repository:
# Clone the repository
git clone https://example.com/repo.git
# Make changes
git add .
git commit -m "Add feature"
# Push to central repository
git push origin main
# If push fails due to upstream changes
git pull --rebase
git push origin main
Fork and Pull Request Workflow
Common in open-source projects:
Fork and clone
# Fork via web interface, then clone your fork
git clone https://github.com/yourname/project.git
cd project
# Add upstream remote
git remote add upstream https://github.com/original/project.git
Create feature branch
git switch -c fix-bug-123
# Make changes and commit
git commit -am "Fix issue #123"
Push to your fork
git push origin fix-bug-123
Create pull request
Use the web interface to create a pull request from your fork’s branch to the upstream repository.
Keep fork synchronized
git fetch upstream
git switch main
git merge upstream/main
git push origin main
Lieutenant and Dictator Workflow
Used by large projects like the Linux kernel:
- Dictator: Integrates changes from lieutenants into official repository
- Lieutenants: Each manages a subsystem, integrating changes from developers
- Developers: Work on features and submit to appropriate lieutenant
# Developer submits patches
git format-patch origin/main
git send-email --to=lieutenant@project.org *.patch
# Lieutenant reviews and applies
git am < patch-file.patch
git push
# Dictator pulls from lieutenants
git pull https://lieutenant.example.com/repo subsystem-branch
Managing Contributions
Applying Patches
When receiving patches via email:
# Apply a single patch
git am < 0001-fix-bug.patch
# Apply with three-way merge on conflicts
git am -3 < 0001-fix-bug.patch
# Apply entire patch series
git am *.patch
# Sign off on applied patches
git am -s < patch.patch
# Fix conflicts in files
# Then stage the resolved files
git add resolved-file.c
# Continue applying
git am --continue
# Or skip this patch
git am --skip
# Or abort
git am --abort
Creating Pull Requests
Generate a formatted summary for pull requests:
git request-pull origin/main https://yourserver.com/repo.git feature-branch
- Where to pull from
- What branch to pull
- A summary of changes
- Diffstat of changes
Reviewing Pull Requests
Fetch the pull request
git fetch origin pull/123/head:pr-123
git switch pr-123
Review changes
git log main..pr-123
git diff main...pr-123
Test the changes
# Run tests, try the feature
npm test
Merge or request changes
# If approved
git switch main
git merge --no-ff pr-123
git push origin main
# Or request changes via web interface
Communication Best Practices
Writing Good Commit Messages
Commit messages are crucial for collaboration:
Short summary (50 chars or less)
More detailed explanatory text, if necessary. Wrap it to about 72
characters. The blank line separating the summary from the body is
critical.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences?
- Bullet points are okay too
- Use imperative mood: "Fix bug" not "Fixed bug"
Resolves: #123
See also: #456, #789
Pull Request Descriptions
Provide context for reviewers:
## Summary
Brief description of what this PR does.
## Motivation
Why is this change needed?
## Changes
- Bullet list of key changes
- Keep it focused
## Testing
How was this tested?
## Screenshots
(If applicable)
## Checklist
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Changelog updated
Code Review Guidelines
For authors:
- Keep pull requests focused and reasonably sized
- Respond to feedback promptly and professionally
- Don’t take criticism personally - it’s about the code
- Update the PR based on feedback
For reviewers:
- Be respectful and constructive
- Explain why changes are needed
- Approve good work promptly
- Consider suggesting rather than demanding
- Focus on important issues
Advanced Collaboration Topics
Using Multiple Remotes
# Clone from your fork
git clone https://github.com/yourname/project.git
# Add upstream and other contributors
git remote add upstream https://github.com/original/project.git
git remote add alice https://github.com/alice/project.git
git remote add bob https://github.com/bob/project.git
# Fetch from everyone
git fetch --all
# Review Alice's work
git log --oneline HEAD..alice/feature-x
# Cherry-pick interesting commits
git cherry-pick alice/feature-x~3
Sharing Work in Progress
Sometimes you need to share incomplete work:
# Push a WIP branch
git push -u origin wip/experimental-feature
# Mark commits as WIP in messages
git commit -m "WIP: Experimenting with new approach"
# Or use draft pull requests
# Create via web interface as draft
Prefix branch names with wip/ to clearly indicate work-in-progress branches that may be rebased or force-pushed.
Pair Programming with Git
# Co-author commits
git commit -m "Implement feature
Co-authored-by: Partner Name <partner@example.com>"
# Or use git-pair or mob tool
Collaboration Etiquette
- Communicate clearly: Use descriptive branch names, commit messages, and PR descriptions
- Respect the workflow: Follow your team’s established processes
- Test before pushing: Don’t break the build for others
- Pull before pushing: Stay in sync with the team
- Keep history clean: Use meaningful commits, consider squashing
- Be responsive: Reply to reviews and comments promptly
- Ask for help: Don’t struggle alone - collaboration is about teamwork
Always coordinate with your team before:
- Force pushing to shared branches
- Rewriting published history
- Changing release tags
- Modifying CI/CD configurations
