Pull requests (PR) and code review

01 / 10

Preventing direct pushes to main

In the previous chapter, you worked directly on the main branch and ran git push to send commits to the remote repository. That works fine when you are developing alone.

However, in a team with multiple developers, pushing directly to main causes serious issues:

Broken code gets pushed to main, stopping the entire team from working
Bad architecture or security flaws slip into production without anyone noticing
It becomes difficult to trace who made which change and why

For this reason, software development teams establish a strict workflow rule: never push directly to main; always review code before merging.

02 / 10

A pull request is not a Git feature

This is an essential distinction.

Pull requests (PRs) and Issues are not built-in features of Git. There is no git pull-request command.

These features are built on top of Git by remote hosting platforms such as GitHub and GitLab (where they are called "Merge Requests" or MRs).

Because of this, PR and Issue operations in this course are performed using the UI tabs and buttons of the remote repository (GitHub) rather than terminal commands.

03 / 10

Issues — Tracking tasks and requirements

In team development, you rarely start coding without a recorded requirement.

First, bug reports and feature requests are created as Issues.

Each Issue receives a unique number (#1, #2...) where assignees, discussion comments, and status updates are tracked. Developers create a branch to resolve the issue and begin their implementation.

04 / 10

The PR workflow cycle (6 steps)

Team development follows these six standard steps:

1. Create a feature branch and commit your changes (git switch -c feature)
2. Push the branch to the remote repository (git push origin feature)
3. Open a pull request (PR) on GitHub
4. Teammates review the code changes, leave review comments, and approve
5. Once approved, merge the PR into main on GitHub (Merge pull request)
6. On your local machine, run git switch main and git pull to update your local main

05 / 10

PRs target branches that have already been pushed

If you try to open a pull request but cannot find your branch in the dropdown, it means you have not pushed your local branch to the remote repository yet.

A pull request asks the remote repository to merge a branch that exists on the remote into main. It cannot reference a branch that only exists locally.

Therefore, the order must always be: run git push first, then open the pull request.

06 / 10

Review and address feedback (push additional commits)

Once a PR is open, teammates can inspect the diff and leave comments.

If a reviewer asks for changes (such as renaming a function or adding tests), you do not need to close or recreate the PR.

Simply edit the files locally, create a new commit, and run git push to the same branch. The open pull request updates automatically with the new commits.

07 / 10

Merging a PR (creates a merge commit on remote)

When your PR is approved, click "Merge pull request" on GitHub.

Clicking this button executes git merge on the remote server (GitHub). A merge commit uniting your branch into main is created on the remote repository.

The GitHub UI button is simply an interface for executing a remote merge operation.

$ git log --oneline4c8e2a1 Merge pull request #1 from ramen9f2a1c4 added ramen

08 / 10

Local main does not update automatically

This is the most common pitfall for beginners.

Merging a pull request on GitHub does not automatically update the main branch in your local repository.

The remote repository and your local repository are separate environments. To synchronize changes made on the remote into your local machine, you must explicitly fetch and integrate them.

After a PR is merged, always run git switch main followed by git pull to update your local branch.

09 / 10

Resolving PR merge conflicts

If another developer's PR is merged into main while your PR is still open, and both touched the same lines of code, a merge conflict occurs and the merge button will be disabled.

Resolving the conflict is the author's responsibility:

1. Fetch the latest changes with git fetch
2. On your feature branch, run git merge origin/main
3. Resolve the conflict markers in the affected files and commit the resolution
4. Run git push to update your feature branch

Once pushed, the conflict is resolved and the PR becomes mergeable again.

10 / 10

Hands-on practice

Now try the complete pull request workflow yourself.

At the bottom of the screen in the remote repository (origin) box, you will find the Pull Requests and Issues tabs. Use these tabs and buttons for PR operations rather than terminal commands.

When creating a PR, select your source branch and enter a title describing your changes.