GitHub Collaboration — Fork, Branch, PR, Team Workflows

Why Collaboration Matters

Modern software development is a team sport. GitHub provides the tools that enable dozens, hundreds, or thousands of developers to work together on the same codebase without stepping on each other's toes. Mastering collaborative workflows is essential for professional development.

Why this matters for your career:

• Team collaboration is the norm in every software company
• Understanding fork vs. branch workflows is essential for open source contribution
• Code review is a daily practice in professional engineering teams
• Git conflict resolution is a skill that separates juniors from seniors

Collaboration Models

Shared Repository Model

All team members have write access to the same repository. Developers create branches, push changes, and open PRs against main.

# Developer A: Clone the shared repo
git clone https://github.com/company/project.git
cd project
git checkout -b feature/new-dashboard
# ... make changes ...
git push -u origin feature/new-dashboard
# Open PR on GitHub

Best for: Small teams, internal projects, where all members are trusted.

Fork and Pull Model

External contributors fork the repository, make changes in their fork, and submit a PR to the original repository.

# Fork the repo on GitHub (click Fork button)
# Then clone your fork
git clone https://github.com/yourusername/project.git
cd project

# Add the original repo as upstream
git remote add upstream https://github.com/originalowner/project.git

# Create a branch, make changes
git checkout -b fix/login-error
# ... fix the bug ...
git push -u origin fix/login-error
# Open PR from your fork to the original repo

Best for: Open source projects, external contributions, when contributors should not have direct write access.

Keeping Your Fork Updated

# Fetch latest changes from upstream
git fetch upstream

# Switch to your main branch
git checkout main

# Merge upstream changes
git merge upstream/main

# Push updates to your fork
git push origin main

Resolving Merge Conflicts

Conflicts occur when two branches modify the same part of a file.

# When merging produces a conflict
git merge feature/new-feature  # Auto-merge fails

# Git marks the conflicted file
# <<<<<<< HEAD
# code from current branch
# =======
# code from the incoming branch
# >>>>>>> feature/new-feature

# Manually edit the file to resolve the conflict
# Remove the <<<<<<, =====, >>>>>> markers
# Keep the correct code

# Mark as resolved and continue
git add resolved-file.js
git commit  # Complete the merge

Conflict Resolution Strategies

| Strategy | When to Use | |----------|-------------| | Accept theirs | The incoming change is definitely correct | | Accept yours | Your change should take priority | | Manual merge | Both changes are valid and need to be combined | | Discuss with author | The conflict is complex or ambiguous | | Rebase and re-apply | When conflicts span many files |

Branch Protection Rules

Protect important branches from direct pushes:

# In GitHub Settings → Branches → Add rule

Branch name pattern: main

Required settings:
✅ Require pull request reviews before merging
✅ Require at least 1 approval
✅ Dismiss stale reviews when new commits are pushed
✅ Require status checks to pass
✅ Require branches to be up to date
✅ Do not allow bypassing the above settings

Code Review Workflow

PR Lifecycle

1. Developer creates PR
2. CI runs tests automatically
3. Reviewer(s) assigned
4. Reviewers leave comments and request changes
5. Developer addresses feedback
6. PR approved and merged
7. Branch deleted (optional)

Review Assignment Strategies

| Strategy | Description | |----------|-------------| | Manual assignment | PR author specifies reviewers | | Auto-assign based on team | GitHub assigns based on team membership | | Round-robin | Load balances across available reviewers | | Code owner | File-based ownership (CODEOWNERS file) |

CODEOWNERS File

# .github/CODEOWNERS
# Global owners
* @team-leads

# Backend code
/api/ @backend-team

# Frontend code
/src/components/ @frontend-team

# Documentation
*.md @docs-team

# Configuration
Dockerfile @devops-team

Team Collaboration Best Practices

| Practice | Benefit | |----------|--------| | Keep PRs small (under 400 lines) | Faster review, fewer conflicts | | Write descriptive PR titles | Reviewers understand the change quickly | | Link issues to PRs | Automatic tracking of work | | Delete branches after merging | Clean repository, no stale branches | | Use draft PRs for work in progress | Signal to reviewers the PR is not ready | | Squash commits on merge | Clean git history | | Use rebase instead of merge for feature branches | Linear history, easier to follow | | Run CI before requesting review | Avoid wasting reviewer time on failing code |

Git Collaboration Commands Cheat Sheet

| Command | Purpose | |---------|--------| | git fetch upstream | Get latest from original repo (fork model) | | git rebase main | Reapply commits on top of main | | git merge main | Merge main into your branch | | git cherry-pick abc123 | Apply a specific commit from another branch | | git stash | Temporarily save uncommitted changes | | git stash pop | Restore stashed changes | | git log --oneline --graph | Visualize branch history | | git diff main...feature | See changes between branches |

Summary

GitHub collaboration is built on branches, pull requests, and code review. Choose the shared repository model for internal team work and the fork model for open source contributions. Branch protection rules enforce quality standards. Good PR practices — small changes, clear descriptions, linked issues — make collaboration smooth and efficient.

Key takeaways:

• Shared repo model: team members create branches and PRs directly
• Fork model: external contributors fork, modify, and submit PRs
• Keep forks updated by syncing with upstream
• Resolve merge conflicts by editing conflicted files manually
• Branch protection rules prevent direct pushes to main
• Small PRs (< 400 lines) are easier and faster to review
• CODEOWNERS file auto-assigns reviewers based on file paths
• Delete branches after merging to keep the repository clean

What's Next: GitHub Portfolio

The next chapter teaches you to build a professional GitHub portfolio — organizing projects, writing great READMEs, and leveraging your profile for job opportunities.