Git Basics #6: GitHub and Your First Pull Request

Tools Git Version Control GitHub Pull Request

Monday, July 13, 2026

7 min read

Parts 1 through 5 covered stacking commits in a local repository, splitting off branches and merging them, syncing with a remote repository, and undoing mistakes. One last piece remains. The biggest difference between Git used alone and Git used on a team is the Pull Request. This procedure — landing a branch’s changes after review — is the standard of modern development collaboration.

It runs in six parts.

#1 What Git is — the snapshot model and the three areas
#2 add, commit, status — what the staging area means
#3 Branching and merging — fast-forward and 3-way
#4 Remotes — clone, fetch, pull, push, and what origin really is
#5 Undoing changes — restore, reset, and revert
#6 GitHub and your first Pull Request ← this post

This post creates a repository on GitHub, connects a local repository to it, then opens a first Pull Request, merges it, and cleans up — the whole flow in order.

What a Pull Request is #

A Pull Request is exactly what the name says: a request. “Please pull my branch’s changes into this branch” — PR for short. In practice, though, the value of a PR lies less in the merge request itself than in what happens on top of it. A PR is the space for review, where teammates read the changed code line by line, talk in comments, and land the changes after revisions.

One distinction is worth making early. A Pull Request is not a feature of Git itself. There is no git pull-request command. The PR is a feature that GitHub, a hosting service, built on top of Git. That is why GitLab calls the same thing a Merge Request. The names differ, the structure is the same. Branches, commits, and pushes belong to Git; reviews and the merge button belong to the hosting service.

Creating a repository on GitHub #

Part 4 covered cloning a remote repository that already exists. This time the direction is reversed: we take a repository that already exists locally and put it up on GitHub.

Log in to GitHub and create a new repository with the New repository button. Choose only the repository name, and leave the README and .gitignore options unchecked. The local repository already has commit history, so the remote must be empty for the push to go up without conflicts.

Once the repository is created, GitHub shows you its address. Register that address under the name origin and push.

Connect the local repository to GitHub

git remote add origin https://github.com/<account>/<repository>.git
git push -u origin main

As covered in part 4, -u ties your local main and the remote main into a tracking pair. Set it once and git push alone is enough from then on.

Your first Pull Request — from branch to merge #

Now we follow the actual working flow from start to finish. The scenario is simple: build a greeting feature on a branch and land it through a PR.

First create a branch, do the work, and commit.

Branch and commit

git switch -c feature/greeting
# write greeting.py
git add greeting.py
git commit -m "feat: add greeting function"

Push this branch to the remote. It is the branch’s first push, so -u goes here as well.

Push the branch

git push -u origin feature/greeting

Right after the push, open the repository page on GitHub and a Compare & pull request button appears for the branch you just pushed. Clicking it takes you to the PR creation screen.

The top of the screen shows the direction. base is the branch that receives the changes, and compare is the branch that sends them. Right now base is main and compare is feature/greeting. Build the habit of checking this direction — it saves you from mistakes later when you move between several branches.

Write the title and description. Two rules of thumb: the title says what you did, and the description says why you did it. Reviewers can see what changed in the code diff, but they cannot know why it changed without an explanation. A paragraph or two of background and intent visibly raises the quality of the review.

Tip

If the PR is not ready for review yet, you can open it as a Draft Pull Request instead. Drafts are often used to check CI results before requesting review, or to share the direction of the work early.

Review comments and follow-up commits #

Once the PR is open, a teammate reviews the code. How do you apply a change they requested? The answer is simple: fix the code on the same branch, commit, and push again.

Apply review feedback

# edit the code on the feature/greeting branch
git add greeting.py
git commit -m "fix: handle empty name input from review"
git push

The PR points at the branch, so pushing new commits to that branch updates the open PR automatically. There is no need to close and reopen it. Review comments, follow-up commits, and re-review repeat in this way, and once approval comes in, it is time to merge.

The three merge buttons #

GitHub’s merge button offers three methods.

Method	What it does	History
Merge commit	Creates a merge commit joining the two histories	branch trace fully preserved
Squash and merge	Combines all branch commits into one and adds it	a single commit lands on main
Rebase and merge	Replays the branch commits on top of main in order	straight line, no merge commit

Merge commit is the same operation as the 3-way merge from part 3. Squash and merge is useful for keeping main’s history clean when the branch is full of small commits like “fix typo” and “apply review”. Rebase and merge is used by teams that prefer linear history.

The rule of thumb at the basics stage is simple: follow your team’s convention. In a repository that is already running, check how earlier PRs were merged and use the same method. On a personal project any of the three works, but early on, when commits tend to pile up messily, Squash and merge is the lower-effort choice.

Cleanup after the merge #

A merged branch has done its job, so clean it up. Delete the remote branch with the Delete branch button that GitHub shows right after the merge, then tidy up locally.

Cleanup after merge

git switch main
git pull
git branch -d feature/greeting

Back on main, pulling brings down the merge result, so your local main now includes the change that just landed. Then delete the local branch with git branch -d. As covered in part 3, deleting a merged branch is a safe operation that loses no commits.

That is one full cycle. We went one lap through branch, commit, push, PR, review, merge, and cleanup, and a working day in practice is this cycle on repeat.

The series in one view #

One line for each of the six parts.

#1 Git records history as snapshots and operates across three areas: the working directory, the staging area, and the repository.
#2 add picks the candidates for the snapshot, and commit turns what was picked into a record.
#3 A branch is a lightweight pointer to a commit, and merges come in two kinds: fast-forward and 3-way.
#4 origin is a nickname for the remote repository’s address, and pull is the combination of fetch and merge.
#5 Undoing splits into restore before a commit, amend and reset before a push, and revert after a push.
#6 A Pull Request is the standard collaboration procedure for landing a branch’s changes after review.

Wrap-up #

The goal of this series was to draw the minimum map you need when first learning Git. If you followed along this far, you have the fundamentals for recording and sharing work with Git, whether alone or on a team.

The next step is the situations of daily practice. A practical workflow series is in the works, covering branch strategies that fit your team size, the criteria for choosing between rebase and merge, cleaning up commits with interactive rebase, and understanding and resolving conflicts structurally. This concludes the Git Basics series.