Git Collaboration: PR Workflows, Code Review & Forking

Effective Git collaboration goes beyond knowing commands. It requires workflows that keep codebases stable, reviews thorough, and teams productive. Whether you are contributing to open source or shipping features with a team of 50 engineers, understanding pull request workflows, code review best practices, forking strategies, and branch naming conventions is essential. According to GitHub’s 2024 Octoverse Report, teams using structured PR workflows deliver 2.4x more merged pull requests per developer than teams without formalized collaboration practices.

Pull Request Workflow

The pull request (PR) is the standard mechanism for code contribution in modern software development. It combines code review, automated testing, and discussion in a single workflow. The PR model was popularized by GitHub and has been adopted by every major code hosting platform.

Creating a PR

1. Create a feature branch from main or the appropriate base branch
2. Commit changes with clear, descriptive messages following conventional commit format
3. Push the branch to the remote repository
4. Open a PR targeting the base branch
5. Add a detailed description explaining what the change does, why it is needed, and how it was tested
6. Add reviewers, labels, and link related issues

Keeping PRs Small

Small PRs review faster, catch more bugs, and merge sooner. The research is clear: PRs over 400 lines have significantly higher defect density and take longer to review. A 2024 study by Microsoft Research found that the optimal PR size for defect detection is 200-300 lines of code changes. Aim for:

• Under 300 lines of code changes (additions + deletions)
• Single concern per PR — one feature, one bug fix, one refactoring
• Self-contained — passes all tests independently and does not depend on unmerged changes

If a feature requires large changes, break it into a stack of small PRs that merge sequentially. Tools like Graphite and GitStack make stacked PR workflow manageable by automatically rebasing dependent branches.

PR Description Template

A good PR description answers:

• What does this change do?
• Why is this change needed? Link to the issue or ticket
• How was it tested? Unit tests, manual testing, staging deployment
• Risks — what could go wrong? Is there a rollback plan?
• Screenshots — for UI changes, include before/after screenshots

Many teams enforce PR descriptions through GitHub issue templates or branch protection rules that require a minimum description length.

Code Review Best Practices

For Reviewers

• Read the description first — understand the intent before examining the implementation
• Review the code, not the author — focus on technical correctness: “This approach might miss edge cases” instead of “You forgot…”
• Distinguish blockers from suggestions — label blocking comments (changes required before merge) vs non-blocking comments (nice-to-have improvements)
• Review in focused sessions — set aside dedicated time for reviews rather than context-switching. Research shows context-switching costs 23 minutes of lost productivity per interruption
• Check for test coverage — every change should include or update tests. Aim for the same coverage level as the surrounding code
• Verify security — look for injection vulnerabilities, exposed secrets, authentication bypasses, and authorization checks
• Review the tests first — understanding how the change is tested reveals whether the test coverage is adequate

For Authors

• Explain your decisions — leave inline comments on tricky parts of the code explaining why you chose a particular approach
• Respond to feedback — acknowledge each comment, accept the suggestion or explain why the current approach is correct
• Rebase before merging — keep a linear history by rebasing on the target branch
• Do not merge your own PRs — another pair of eyes catches blind spots you have
• Update the description — if the implementation changed during review, update the PR description to match

Automated Review Enforcements

Enforce code review policies automatically using branch protection rules and CODEOWNERS files:

# .github/CODEOWNERS
# Require review from specific teams for sensitive files
src/api/          @team-backend
src/database/     @team-data
*.config.js       @team-infrastructure

Branch protection rules enforce:

• Required reviews (1-2 minimum depending on branch sensitivity)
• Stale review dismissal when new commits are pushed
• Required status checks (CI, linting, security scan)
• Linear history requirement

Code Review Velocity

The time a PR spends in review is the largest component of lead time for most teams. To accelerate reviews without sacrificing quality:

• Set explicit SLAs: e.g., “review within 4 business hours”
• Rotate review responsibilities so no single person is a bottleneck
• Use async reviews for simple changes and sync reviews for complex architectural decisions
• Implement “review buddy” pairing where two developers review each other’s code regularly

Forking Workflow

Open-source projects typically use the forking workflow, where contributors fork the upstream repository and submit PRs from their fork:

upstream/repo → your-fork/repo → local clone → PR back to upstream

1. Fork the upstream repository to your GitHub account
2. Clone your fork locally: git clone https://github.com/your-username/repo.git
3. Add the upstream as a remote: git remote add upstream https://github.com/upstream/repo.git
4. Create feature branches from main
5. Push to your fork and open a PR to upstream
6. Keep your fork synced: git fetch upstream && git merge upstream/main

The forking model protects the main repository by enforcing that contributors have no direct write access. All changes flow through PRs reviewed by maintainers. This is the standard model for open-source projects on GitHub and GitLab.

Branch Naming Conventions

Consistent naming helps teams identify branch purpose at a glance:

feature/issue-42-user-auth
fix/issue-99-login-crash
hotfix/issue-100-security-patch
chore/update-deps
docs/api-readme
release/v2.1.0

Include the issue or ticket number for traceability. GitHub and GitLab automatically link branches containing issue numbers when you reference them in PRs. Branch naming conventions should be documented in CONTRIBUTING.md and enforced through CI validation.

Merge Conflict Resolution in Collaborative Workflows

Merge conflicts are inevitable in collaborative development. How you handle them affects team velocity and code quality.

Prevention Strategies

• Small, frequent merges — branches that live longer than a day accumulate more conflicts. Merge or rebase from the target branch at least daily
• Clear ownership — CODEOWNERS file assigns file ownership; coordinate with owners before making significant changes to shared files
• Communication — use the team’s communication channel to announce when you are working on shared code areas
• Trunk-based development — merging to main multiple times per day keeps branches short and reduces conflict probability

Resolution Workflow

When a conflict occurs during merge or rebase:

# Identify conflicting files
git status

# Open each conflicted file and resolve markers
# <<<<<<< HEAD (current branch)
# ======= (divider)
# >>>>>>> feature-branch (incoming changes)

# After resolving all conflicts
git add resolved-file.js
git commit           # For merge
# OR
git add resolved-file.js && git rebase --continue   # For rebase

Tools for Conflict Resolution

Visual merge tools reduce cognitive load during conflict resolution:

# Configure a merge tool
git config --global merge.tool vimdiff
# OR
git config --global merge.tool kdiff3

# Launch merge tool during conflict
git mergetool

Cloud-based merge editors (GitHub’s built-in conflict resolver, GitLab’s Web IDE) are suitable for simple conflicts. For complex conflicts involving multiple files, use a local merge tool with three-pane display (base, local, remote).

Pull Request Automation

Automate repetitive aspects of the PR workflow to keep teams focused on code quality:

# .github/workflows/pr-checks.yml
name: PR Checks
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  size-label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v4
      - name: Check PR size
        run: |
          PR_SIZE=$(git diff --stat main...HEAD | tail -1 | awk '{print $4}')
          if [ "$PR_SIZE" -gt 400 ]; then
            echo "This PR exceeds 400 lines. Consider splitting it."
          fi

Common automations include auto-assigning reviewers based on CODEOWNERS, labeling PRs by size or type, running CI pipelines, and posting preview deployment URLs.

FAQ

How small should a pull request be?

Aim for under 300 lines of code changes. If a change exceeds 500 lines, break it into multiple PRs. The ideal PR is one logical change that an experienced reviewer can fully understand in 15 minutes. Microsoft’s research on PR quality found that defect density increases by 30% when PRs exceed 400 lines.

Should I squash commits when merging?

Squash merge for feature branches with messy commit history. Rebase merge for branches with well-structured, atomic commits. The project maintainer should define the convention in CONTRIBUTING.md. The key is consistency across the project — mixed approaches create a confusing Git history.

How many reviewers should a PR have?

One or two. More than two quickly reaches diminishing returns — each additional reviewer adds communication overhead and delay. Use CODEOWNERS to automatically assign relevant reviewers based on which files changed. The second reviewer should have expertise in the specific area being changed.

What if a code review is blocking my feature?

Proactively communicate with reviewers. Set expectations with a comment: “This PR is ready for review, I will merge by end of day Thursday if no blocking concerns.” If the review is truly stuck, escalate to the tech lead or manager. Some teams implement a “merge window” policy where PRs without blocking feedback within 24 hours can be merged.

How do I handle conflicting feedback from two reviewers?

Comment in the PR summarizing the two positions and your recommendation. Tag both reviewers and the tech lead for a decision. The goal is resolution, not consensus on every detail. The author ultimately makes the final call with the tech lead’s guidance.

Conclusion

Effective Git collaboration relies on small, focused PRs, thorough but respectful code reviews, and consistent branch naming. Choose the workflow that matches your team size and release cadence — forking for open source, shared repository for internal teams. Enforce standards with automation (CODEOWNERS, branch protection, CI status checks) and invest in a culture of constructive, blameless code review.

For advanced Git techniques, explore Git merge strategies and Git hooks for automation.