What is a pull request?
A pull request is a request, made on GitHub, to merge one branch into another. You push a branch such as add-contact, then ask for it to be merged into main. GitHub shows the commits and the line-by-line changes, lets people comment on specific lines, runs any automated checks, and shows a Merge button when everyone is satisfied.
Pull requests are a GitHub feature, not a Git command. Git itself has no git pull-request. GitLab calls the same thing a merge request. Under the hood, the merge button does what you already know: it merges the branch, usually creating a merge commit on main.
Even on a solo project, such as your own profile page, a pull request is a useful habit. It gives you a page that shows the whole change at once, a place to note why you made it, and a chance for automated checks to catch problems before main changes.
add-contact back into main.Which part happens in your terminal?
Everything up to the push. Create a branch from an up-to-date main, make your changes, commit them, and push the branch with -u. That is the part you practise here. The pushed branch appears on GitHub, and GitHub usually shows a yellow banner offering to compare and open a pull request.
Name branches after the change: add-contact, fix-menu-prices, sighting-form. Short, lowercase, with dashes. A clear name tells reviewers what to expect and makes git branch readable a month later.
git pull
git switch -c add-contact
echo "<p>Email: hello@example.com</p>" >> index.html
git add index.html
git commit -m "Add contact details"
git push -u origin add-contact
git branch -aWhat do you write when opening the pull request?
On GitHub, choose the base branch (where the change should go, normally main) and the compare branch (your add-contact). Give it a title that says what it does, such as Add contact details to profile, and a description that answers three questions: what changed, why, and how to check it.
For a web page, the checking instructions can be short: open index.html, confirm the email line appears under the introduction and that the link works. Screenshots help reviewers who do not want to run the site themselves. If the pull request is not ready, open it as a draft so nobody merges it by accident.
- Title: what the change does, in a few words.
- Description: why it was needed and anything a reviewer should look at closely.
- How to test: the steps or the page to open.
- Draft if you are still working on it.
What happens during review?
Reviewers read the Files changed tab and leave comments on lines. They can approve, ask for changes, or only comment. Automated checks, for example a spelling check or a test run, appear at the bottom with a tick or a cross. Many teams protect main so that nothing merges until checks pass and someone approves.
Treat comments as questions about the code, not about you. Reply to each one: fix it, or explain why you kept it. When you change something, resolve the conversation so the reviewer can see what is left.
How do you update a pull request after feedback?
You do not open a new one. Stay on the same branch, make the change, commit, and run git push. Because you set the upstream with -u, a bare push is enough. GitHub adds the new commit to the open pull request and reruns the checks.
If main moved on while you waited and GitHub reports a conflict, merge main into your branch locally: git switch add-contact, git pull origin main, resolve any conflict, commit and push. The pull request updates itself. Avoid force pushing to a branch someone is reviewing, because it rewrites the commits they already commented on.
git switch -c add-contact
echo "<p>Email: hello@example.com</p>" >> index.html
git commit -am "Add contact details"
git push -u origin add-contact
echo "<p>Replies within two days.</p>" >> index.html
git commit -am "Mention reply time"
git pushWhat do the merge options on GitHub mean?
GitHub offers up to three buttons, depending on the repository's settings. Create a merge commit keeps every commit from the branch and adds a merge commit, the same result as git merge --no-ff. Squash and merge combines all the branch's commits into one new commit on main, which keeps history short. Rebase and merge replays each commit on top of main without a merge commit.
Any of them is fine for a small personal project. On a team, use whatever the repository is set up for. After squash or rebase merging, the commits on main have different ids from the ones on your branch, so git branch -d may say the branch is not fully merged even though the change is in. Check the change is on main, then delete the branch.
How do you tidy up after the merge?
After GitHub merges the pull request, your local main does not know yet. Switch to it and pull: git switch main, then git pull. Now the contact details are in your main. Delete the finished branch locally with git branch -d add-contact, and on GitHub with the Delete branch button that appears after merging.
Then start the next change from this fresh main. Starting each branch from an up-to-date main keeps pull requests small and conflicts rare. If you forget and branch from an old main, the pull request will show changes you did not make, which confuses reviewers.
git switch -c add-contact
git switch main
git pull
git branch -d add-contact
git branchWhat do AI tools get wrong here?
Assistants sometimes tell you to commit and push straight to main with git push origin main, skipping the branch. On a protected repository that push is refused, and on an unprotected one it skips the review you wanted. If a tool says to push to main, check whether the project expects pull requests.
They also invent commands such as git pull-request or git pr create. Neither is part of Git. GitHub's own command-line tool has gh pr create, which opens a pull request from the terminal after you have pushed, but it is a separate program you install and log in to.
Field notes
- A pull request asks for one branch to be merged into another, with room for review.
- Your terminal work ends with pushing the branch using
-u. - To answer feedback, commit on the same branch and push again.
- After the merge, switch to
main, pull, and delete the finished branch.
Easy to get wrong
A pull request needs a separate branch to compare with main. Committing on main skips review entirely.
One pull request keeps the whole conversation and the review history together.
A new branch from an old main brings back conflicts that were already solved.
Questions people ask
Can I open a pull request without pushing?
No. GitHub can only compare branches it has, so the branch must be pushed first.
Why is it called a pull request when I pushed?
You push your branch, then request that the project owner pull (merge) it into their branch. The name comes from that second step.
What is a fork?
A copy of someone else's repository under your own account. You push branches to your fork and open pull requests from it into the original when you cannot push there directly.
Can I merge my own pull request?
On your own repository, yes, unless branch protection says otherwise. Reading the Files changed tab before merging still catches mistakes.