Pull request process in Git - Deep Dive

Overview - Pull request process

What is it?

A pull request is a way to ask a team to review and merge your code changes into a shared project. It lets others see what you changed, discuss it, and suggest improvements before adding it to the main code. This process helps keep the project organized and high quality. It is common in collaborative software development using Git.

Why it matters

Without pull requests, code changes could be added without review, causing bugs or conflicts that are hard to fix later. Pull requests create a safety net by encouraging discussion and testing before merging. This improves code quality, team communication, and reduces mistakes that could break the project.

Where it fits

Before learning pull requests, you should understand basic Git commands like commit, branch, and push. After mastering pull requests, you can learn advanced topics like continuous integration, code review best practices, and automated testing in pipelines.

Mental Model

Core Idea

A pull request is a formal way to propose, review, and discuss code changes before merging them into the main project.

Think of it like...

It's like writing a draft of a group report and sharing it with your teammates to get feedback and approval before submitting the final version.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Developer   │──────▶│ Create branch │──────▶│ Make changes  │
└─────────────┘       └───────────────┘       └───────────────┘
       │                      │                       │
       │                      ▼                       │
       │              ┌───────────────┐              │
       │              │ Push branch   │              │
       │              └───────────────┘              │
       │                      │                       │
       │                      ▼                       │
       │              ┌───────────────┐              │
       │              │ Open pull     │              │
       │              │ request       │              │
       │              └───────────────┘              │
       │                      │                       │
       │                      ▼                       │
┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Reviewers   │◀──────│ Review &      │◀──────│ Discuss &     │
│ discuss and │       │ comment       │       │ improve code  │
│ approve or  │       └───────────────┘       └───────────────┘
│ request     │
│ changes     │
└─────────────┘
       │
       ▼
┌─────────────┐
│ Merge code  │
│ into main   │
│ branch      │
└─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Git branches basics

Concept: Learn what branches are and why they help keep code changes separate.

In Git, a branch is like a separate workspace where you can make changes without affecting the main project. This lets you work on new features or fixes safely. You can switch between branches and keep your work organized.

Result

You can create and switch branches to isolate your work from others.

Knowing branches is essential because pull requests rely on comparing changes between branches.

2

Foundation

Making and committing code changes

Concept: Learn how to save your changes locally with commits.

After editing files, you use 'git add' to stage changes and 'git commit' to save them with a message. Commits are snapshots of your work that you can share or revert later.

Result

Your changes are saved in the branch history as commits.

Understanding commits helps you track what changed and why, which is key for pull request reviews.

3

Intermediate

Pushing branches to remote repository

🤔Before reading on: do you think pushing a branch updates the main project directly or just uploads your changes for sharing? Commit to your answer.

Concept: Learn how to upload your branch and commits to the shared server.

Use 'git push origin branch-name' to send your local branch and commits to the remote repository. This makes your work visible to others and ready for collaboration.

Result

Your branch appears on the remote server, accessible to teammates.

Knowing that push shares your work but does not merge it prevents accidental changes to the main project.

4

Intermediate

Creating a pull request for review

🤔Before reading on: do you think a pull request automatically merges code or starts a discussion? Commit to your answer.

Concept: Learn how to formally propose your changes for review and merging.

On platforms like GitHub or GitLab, you open a pull request by selecting your branch and the target branch (usually main). You add a title and description explaining your changes. This starts a conversation where others can review and comment.

Result

A pull request is created, visible to the team for review.

Understanding that pull requests are about collaboration and quality control helps you write better change descriptions.

5

Intermediate

Reviewing and discussing pull requests

🤔Before reading on: do you think reviewers can change code directly or only comment? Commit to your answer.

Concept: Learn how team members check code, suggest improvements, and approve changes.

Reviewers read the code differences, leave comments, and ask questions. They may request changes or approve the pull request. The author can update the branch with fixes based on feedback.

Result

The pull request evolves through discussion until it is ready to merge.

Knowing that review is a dialogue improves teamwork and code quality.

6

Advanced

Merging pull requests safely

🤔Before reading on: do you think merging deletes the feature branch automatically? Commit to your answer.

Concept: Learn how to combine approved changes into the main project without breaking it.

Once approved, the pull request can be merged using options like 'merge commit', 'squash', or 'rebase'. This adds your changes to the main branch. Often, the feature branch is deleted after merging to keep the repository clean.

Result

Your changes become part of the main project history.

Understanding merge options helps maintain a clean and understandable project history.

7

Expert

Handling conflicts and automation in pull requests

🤔Before reading on: do you think conflicts block merging until fixed or can they be ignored? Commit to your answer.

Concept: Learn how to resolve code conflicts and use automation tools in pull requests.

Conflicts happen when changes clash with others. They must be fixed manually before merging. Many teams use automated tests and checks triggered by pull requests to ensure code quality and prevent errors.

Result

Conflicts are resolved, and automated checks pass before merging.

Knowing how to handle conflicts and automation prevents broken code from entering the main project.

Under the Hood

A pull request works by comparing the changes between two branches in the Git repository. The platform tracks commits and file differences, allowing reviewers to see exactly what changed. When merging, Git applies these changes to the target branch, updating its history. Automation hooks can run tests or checks triggered by pull request events.

Why designed this way?

Pull requests were created to improve collaboration in distributed teams by formalizing code review and discussion. They prevent direct pushes to main branches, reducing errors. Alternatives like direct commits lacked review and traceability, leading to unstable projects.

┌─────────────┐      ┌───────────────┐      ┌───────────────┐
│ Feature     │─────▶│ Pull Request  │─────▶│ Merge to Main │
│ Branch      │      │ (Compare diff)│      │ Branch        │
└─────────────┘      └───────────────┘      └───────────────┘
       │                    │                      │
       ▼                    ▼                      ▼
┌─────────────┐      ┌───────────────┐      ┌───────────────┐
│ Commits     │      │ Review &      │      │ Updated Main  │
│ & Changes   │      │ Discussion    │      │ History       │
└─────────────┘      └───────────────┘      └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does creating a pull request automatically merge your code? Commit to yes or no.

Common Belief: Creating a pull request immediately adds your changes to the main project.

Reality: A pull request only proposes changes; merging happens separately after review and approval.

Why it matters: Assuming automatic merge can cause confusion and unexpected project states if changes are not reviewed.

Quick: Can reviewers directly change your code in a pull request? Commit to yes or no.

Common Belief: Reviewers can edit your code directly in the pull request without your involvement.

Reality: Reviewers usually comment and request changes; the author updates the code by pushing new commits.

Why it matters: Misunderstanding this can lead to poor collaboration and unclear responsibility for code changes.

Quick: Is it safe to merge a pull request with unresolved conflicts? Commit to yes or no.

Common Belief: You can merge pull requests even if there are conflicts with the main branch.

Reality: Conflicts must be resolved before merging to avoid breaking the project.

Why it matters: Ignoring conflicts can cause broken builds and lost work.

Quick: Does deleting a feature branch after merging remove the code from the project? Commit to yes or no.

Common Belief: Deleting the feature branch deletes the code changes from the project.

Reality: Deleting the branch only removes the pointer; the merged code remains in the main branch history.

Why it matters: Confusing branch deletion with code removal can cause unnecessary fear or hesitation.

Expert Zone

1

Pull request merge strategies (merge commit, squash, rebase) affect project history clarity and should be chosen based on team preferences.

2

Automated checks integrated with pull requests can block merges until tests pass, enforcing quality gates.

3

Review comments can be resolved or marked as outdated when code changes, helping track feedback status.

When NOT to use

Pull requests are less useful for solo projects or very small teams where direct commits are faster. In such cases, lightweight code review or pair programming may be better.

Production Patterns

In large teams, pull requests are combined with continuous integration pipelines that run tests and code analysis automatically. Some projects use templates and required reviewers to standardize the process.

Connections

Code Review

Pull requests are a tool to perform code review collaboratively.

Understanding pull requests deepens knowledge of how code review improves software quality and team communication.

Continuous Integration (CI)

Pull requests often trigger CI pipelines to test code before merging.

Knowing how pull requests integrate with CI helps ensure only tested code enters the main branch.

Peer Feedback in Education

Pull requests mirror peer feedback where students review and improve each other's work.

Recognizing this connection shows how collaborative review processes foster learning and quality in different fields.

Common Pitfalls

#1 Merging pull requests without resolving conflicts first.

Wrong approach:

git merge feature-branch
# merges even if conflicts exist without fixing

Correct approach:

git checkout feature-branch
# fix conflicts manually
# commit fixes
# then merge into main

Root cause:

Not understanding that conflicts must be fixed to keep project stable.

#2 Pushing directly to main branch instead of using pull requests.

Wrong approach:

git checkout main
git push origin main
# bypasses review process

Correct approach:

git checkout -b feature-branch
# make changes
# push branch
# open pull request

Root cause:

Ignoring the value of code review and collaboration.

#3 Closing pull requests without merging changes.

Wrong approach:

Close pull request in UI without merging or applying changes.

Correct approach:

Merge pull request after approval or update branch and re-request review.

Root cause:

Misunderstanding pull request lifecycle and losing valuable work.

Key Takeaways

Pull requests are a formal way to propose and review code changes before merging into the main project.

They improve code quality by enabling discussion, feedback, and automated testing.

Understanding branches, commits, and pushing is essential to use pull requests effectively.

Merging requires resolving conflicts and choosing the right strategy to keep history clean.

Pull requests integrate with continuous integration and code review to support professional software development.