GitHub + Git: Push, Pull, and Pull Requests

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

If remotes still feel fuzzy, read Git Remote first.

How Do You Push Local Commits to GitHub?

Use git push:

git push origin main

That sends your local main branches commits to up to the origin/main branch.

You can also push to a differently named remote branch (though tbh I usually like to keep my branches in sync):

git push origin local_branch:remote_branch

To delete a remote branch, use the --delete flag:

git push origin --delete remote_branch

What Does git pull Actually Do?

git pull is basically fetch + integrate (which can be “merge” or “rebase” depending on your preference):

git pull origin main

It grabs new remote commits and then merges (or rebases, depending on your config) into your current branch.

If you want explicit control, do it in two steps with git fetch then git merge (or git rebase). That can make debugging easier when things get weird. If you prefer rebase (as I do), then use set this config globally:

git config --global pull.rebase true

If you do, all your future pulls will integrate changes with a rebase operation by default.

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 typicall 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.