Unit 5.2 – Tutorial 2: PRs & Conflicts

Overview

Pull requests are the heart of collaborative development. This tutorial covers the PR workflow, code review best practices, understanding and resolving merge conflicts, and the eternal debate: rebase vs merge. You'll learn to collaborate effectively and keep your repository clean.

Why this matters: Pull requests enable code review, quality control, and knowledge sharing. Conflict resolution is an inevitable skill in team development. Mastering these will make you a more effective collaborator.

1. Pull Request Workflow

A typical PR workflow:

Create a feature branch from main.
Make changes and commit.
Push the branch and open a PR.
Reviewers comment and request changes.
Address feedback with additional commits.
Automated CI runs (tests, linting).
Merge the PR (squash, rebase, or merge commit).
Delete the feature branch.

                        # Step‑by‑step PR commands
                        git checkout -b feature/new-feature
                        git add .
                        git commit -m "Add new feature"
                        git push origin feature/new-feature
                        # Open PR on GitHub/GitLab
                        # After review, update
                        git add .
                        git commit -m "Address review feedback"
                        git push origin feature/new-feature
                        # Merge via UI or command line
                        git checkout main
                        git pull origin main
                        git merge --squash feature/new-feature
                        git commit -m "Merge feature/new-feature"
                        git push origin main
                    

2. Code Review Best Practices

Be respectful: Focus on code, not the person.
Use a checklist: Functionality, performance, security, style, tests.
Keep PRs small: 200‑400 lines max. Easier to review.
Provide context: Describe what and why.
Request changes explicitly: Use "required" vs "nit" labels.
Automate where possible: Use linters and CI.

                        // Example PR description template
                        ## Description
                        [What does this PR do?]

                        ## Why
                        [Why is this needed?]

                        ## Changes
                        - List of changes

                        ## Testing
                        - How was this tested?
                    

3. Understanding Merge Conflicts

A merge conflict occurs when the same lines of code are modified in two different branches. Git cannot determine which change to keep.

                        // Conflict markers in a file
                        <<<<<<< HEAD console.log("Hello from main");=======console.log("Hello from feature");>>>>>>>
                            feature/new-feature

                            // You need to resolve by choosing one or combining them.
                            console.log("Hello from both versions!");
                    

Common causes:

Two developers editing the same file.
Long‑lived branches that diverge significantly.
Refactoring that changes file structure.

4. Resolving Merge Conflicts

Manual resolution

git status – see conflicting files.
Edit files to resolve conflicts (remove markers).
git add to mark as resolved.
git commit to complete the merge.

Using a merge tool

                        # Use a GUI tool
                        git mergetool

                        # Or VSCode's built‑in conflict resolver
                    

Abort if needed

                        git merge --abort
                        git rebase --abort
                    

Best practice: Pull latest main into your feature branch frequently to reduce merge conflicts.

5. Rebase vs Merge

Merge

Preserves complete history (including branch structure).
Creates a merge commit.
Simpler for beginners.

Rebase

Moves the branch to a new base commit.
Rewrites commit history (clean, linear).
Can be dangerous if pushed to shared branches.

                        // Merge vs Rebase visual
                        // Merge: *---*---*---* main
                        // \ /
                        // *---*---* feature
                        // Rebase: *---*---*---*---* main
                        // |
                        // *---* feature (moved)
                    

Recommendation: Use rebase for local feature branches before merging to keep history clean. Use merge for integrating into shared branches.

Quiz

Question 1

What is the purpose of a pull request?

To download code
To propose and review changes before merging
To delete a branch
To run tests automatically

Show answer

B. To propose and review changes before merging.

Question 2

What does the `<<<<<<< HEAD` marker in a conflict indicate?

The current branch's version
The other branch's version
The end of the conflict block
A syntax error

Show answer

A. The current branch's version.

Question 3

What is the main advantage of rebasing over merging?

It creates a merge commit
It preserves a linear commit history
It is always safe
It automatically resolves conflicts

Show answer

B. It preserves a linear commit history.

Exercises

Exercise 1

Simulate a merge conflict: create two branches, modify the same line in the same file, and then resolve the conflict manually.

Sample answer

git checkout -b branch-a – change line 5 to "Version A".
git checkout -b branch-b – change same line to "Version B".
git checkout main, then git merge branch-a (ok).
git merge branch-b – conflict occurs.
Resolve by editing the file (choose one or combine).
git add and git commit.

Exercise 2

Describe the steps to rebase a feature branch onto the latest main branch.

Sample answer

git checkout feature/branch
git fetch origin
git rebase origin/main
If conflicts, resolve and git add then git rebase --continue.
git push --force-with-lease (if pushed before).

Homework

Homework 1

In your capstone repository, practice the PR workflow. Create a feature branch, make changes, open a PR, address feedback (simulated), and merge. Document the process and any conflicts you encountered.

Sample outline

Branch: feature/fix-typo
Changes: Fixed a typo in README.md
PR: Opened and requested review.
Feedback: Add more detail.
Conflict: None encountered.
Merge: Squashed and merged.

Mini‑Project

PR Workflow Simulation

Simulate a team PR workflow with at least 3 contributors. Each contributor works on a separate feature, opens PRs, reviews each other's code, and resolves conflicts (introduce deliberate conflicts).

Sample outline

Contributor A: Adds a new API endpoint.
Contributor B: Updates the same endpoint in a different way (conflict).
Contributor C: Adds tests for the endpoint.
Process: Each opens a PR, reviews, and merges in order.
Conflict resolution: Resolve conflicts by combining changes.

Tutorial Summary

You learned the full lifecycle of pull requests, code review best practices, how to resolve merge conflicts, and the trade‑offs between rebase and merge. These skills are essential for effective collaboration in any team environment.

Key takeaway: Pull requests are not just about merging code — they're about improving quality, sharing knowledge, and building team culture.

Collaboration, PRs & Conflict Resolution

Overview

1. Pull Request Workflow

2. Code Review Best Practices

3. Understanding Merge Conflicts

4. Resolving Merge Conflicts

Manual resolution

Using a merge tool

Abort if needed

5. Rebase vs Merge

Merge

Rebase

Quiz

Question 1

Question 2

Question 3

Exercises

Exercise 1

Exercise 2

Homework

Homework 1

Mini‑Project

PR Workflow Simulation

Tutorial Summary