Git and GitHub: A Practical Pull Request Workflow

Git is the open-source command-line version control tool, and GitHub is basically just a collaboration on top of it. You can absolutely use Git without GitHub, but for most teams, GitHub (or something similar) is where a lot of the collaboration happens. Linus Torvalds created Git, and... well we don't talk about who owns GitHub these days...

All the content from our Boot.dev courses are available for free here on the blog. This one is the "GitHub" chapter of Learn Git. If you want to try the far more immersive version of the course, do check it out!

What's the Difference Between Git and GitHub?

• Git is the open-source CLI tool that tracks code history.
• GitHub is a hosted product that stores Git repos and adds collaboration features.

That means:

• Git manages your commits, branches, and merges.
• GitHub adds pull requests, UI reviews, branch protections, and remote hosting.

You can swap GitHub for GitLab or Bitbucket (or any other alternative hosting provider) and still use the same core Git commands.

How Do You Connect a Local Repo to GitHub?

Create a repo on GitHub, then add it as your remote origin:

git remote add origin https://github.com/your-username/your-repo.git

If you're using SSH auth, you'd use the SSH URL instead.

Once connected, verify with:

git ls-remote

Adding origin only stores the connection. Git Remote explains what remotes and remote-tracking branches are.

How Do You Push Local Commits to GitHub?

Use git push to send your local commits to GitHub:

git push origin main

That sends your local main branch's commits to origin/main. To set that remote branch as the default upstream at the same time, see What Does git push -u origin main Do?. For the other direction, including how pull combines fetch with merge or rebase, read Git Push vs Pull.

What is a Pull Request?

A pull request (PR) lets you:

• show proposed changes,
• discuss them,
• run checks,
• and merge after review.

To create a PR (or in GitLab, it's called a "merge request", but it's basically the same) you push a new branch to GitHub that contains your proposed changes, then open a PR to merge that branch into the target branch (often main).

To be a good citizen, you should typically rebase your branch onto the latest main (or whatever the repo uses as the mainline) before opening the PR. That usually reduces merge pain by keeping your branch up to date, but it doesn't guarantee a conflict-free merge if main keeps moving. It can also make a fast-forward merge possible, but whether the PR actually fast-forwards depends on repo settings and what changes land after your rebase.

What Does a Practical Team Workflow Look Like?

The lightweight version of a Git workflow for a team might look like this:

1. git pull origin main to ensure you have the latest code
2. git switch -c my-feature to create a new my-feature branch
3. Make changes
4. Commit the changes
5. git push origin my-feature to push the branch to GitHub
6. Open a PR on GitHub to merge the remote my-feature into remote main
7. Get a review and approval from another maintainer
8. Merge the PR on GitHub

All this said, if you're working on a solo project, there's nothing wrong with just staying on main and pushing it to the remote main directly. The PR workflow is really designed for collaboration between devs.