Pull Requests

A pull request (PR), also called a merge request on GitLab, is an integration request: “here is my work on a branch, please review it then merge it into main”. It is the meeting point between the code and the team.

A PR is not just a “merge” button. It is a discussion space around the code: comments, suggestions, automated tests, validation. That is where quality is decided.

Before opening a PR, you must have pushed your branch to GitHub.

Step 1 — Push the branch:

git switch feature/recherche
git push -u origin feature/recherche

Step 2 — Open the PR (two options):

• On the GitHub interface: a “Compare & pull request” banner appears; you click, you choose the base branch (main) and the compare branch (feature/recherche).
• On the command line with GitHub CLI:

# Create the PR without leaving the terminal
gh pr create --base main --head feature/recherche \
  --title "Add search" \
  --body "Implements the search bar with filters."

A good PR description contains:

The title and description are read by busy humans. Be explicit: “Fix the crash on login” is a thousand times better than “fix bug”.

🔧 Mini-exercise — From the current branch feature/recherche, create a pull request toward main with gh, giving a clear title.

gh pr create --base main --head feature/recherche \
  --title "Add search" --body "Implements the search bar."

Code review is the heart of the PR: one or more colleagues read the changes, ask questions, suggest improvements, and end up approving or requesting changes.

The three possible verdicts on GitHub:

On the author's side, after comments, you fix and push again: the PR updates automatically.

# Fix after the review
git switch feature/recherche
# ... changes ...
git commit -am "Address review feedback"
git push          # the PR updates on its own

What a good reviewer looks at:

• Does the code do what it claims? (correct logic)
• Is it readable and maintainable?
• Are there tests? Does CI pass green?
• Any security or performance issues?

Code review is not a judgment of the person, but a collective improvement of the product. You criticize the code, never the author. And you also highlight what is well done.

Once the PR is approved and CI is green, you merge it. GitHub offers three methods, which change the shape of the history.

# Merge from the terminal with GitHub CLI
gh pr merge 42 --squash --delete-branch

After the merge, you clean up:

# Delete the remote branch (often automatic)
git push origin --delete feature/recherche

# Update your local
git switch main
git pull origin main

# Delete the local branch
git branch -d feature/recherche

Squash and merge is very popular: one feature = one clean commit in main. The history becomes a readable list of features, not a mess of “wip”, “fix typo”, “oops”.

🔧 Mini-exercise — With gh, merge PR number 42 as a squash and delete the branch in the same step. Write the command.

An effective PR is a small, clear, and tested PR. Here are the habits of high-performing teams.

# Automatically link an issue in the description
gh pr create --title "Add CSV export" \
  --body "Allows exporting the data as CSV. Closes #57"

A 1,000-line PR gets an “LGTM” (looks good to me) without a real review — nobody has the courage to read everything. A 50-line PR gets valuable feedback. Small = reviewed seriously.

🔧 Mini-exercise — Which keyword do you add in a PR description to automatically close issue #57 on merge?

Question 1: What is a pull request for?

a) Deleting a branch

b) Asking for the review and integration of one branch into another

c) Installing Git

d) Cloning a repository

Question 2: What must you do before you can open a PR on GitHub?

a) Delete main

b) Push your branch to the remote repository (git push)

c) Close the terminal

d) Disable CI

Question 3: What does “Request changes” mean during a review?

a) The code is approved

b) Corrections are needed before the merge

c) The PR is deleted

d) A new repository is created

Question 4: Which merge method squashes every commit of the branch into one?

a) Create a merge commit

b) Squash and merge

c) Rebase and merge

d) Cherry-pick

Question 5: Why prefer small pull requests?

a) They use less disk

b) They are reviewed faster and more seriously

c) GitHub makes them mandatory

d) They avoid writing tests

Instructions

You have finished a feature on the branch feature/footer. Complete the full cycle of a pull request with GitHub CLI (gh):

1. Push the branch.
2. Open a PR toward main with a clear title and an issue link (Closes #12).
3. Once approved, merge it as a squash and delete the branch.
4. Update your local repository.

Correction

# 1. Push the branch
git switch feature/footer
git push -u origin feature/footer

# 2. Open the pull request
gh pr create --base main --head feature/footer \
  --title "Add the site footer" \
  --body "Adds a responsive footer with links and legal notices. Closes #12"

# 3. After approval: squash merge + delete the branch
gh pr merge --squash --delete-branch

# 4. Update local
git switch main
git pull origin main
git branch -d feature/footer

Expected result:

$ git log --oneline -1
a1b2c3d Add the site footer (#13)

The number in parentheses (#13) is added automatically by GitHub: it is the PR number. Clicking it brings you back to the entire review discussion. Full traceability.

Key takeaways

1. A pull request asks for the review then the merge of a branch: it is a discussion space.
2. Create a PR: push the branch, then open it via the interface or gh pr create.
3. Code review ends in Approve, Request changes, or Comment; you criticize the code, not the author.
4. Three merge methods: merge commit, squash and merge, rebase and merge.
5. Good practices: small PRs, one topic, green CI, linked issue.
6. After merge: delete the branch and update your local.

What's next

You master the contribution cycle on your repository. Lesson 04 — Collaborative workflow opens wider collaboration: fork, clone, issues, and team good practices.