Learn / Programming / Git & Command Line / Remotes, GitHub and Pull Requests

Git & Command Line · Lesson 4 of 5

Remotes, GitHub and Pull Requests

Push, pull, fork and review code with pull requests.

  • Intermediate
  • 15 min read
  • 3 objectives

Before this lessonLesson 3: Branching and Merging

What you will learn

  • Push and pull
  • Open a pull request
  • Keep a fork up to date

So far everything lived on your machine. A remote is a copy of the repository hosted elsewhere, usually on GitHub, GitLab or Bitbucket. It is how you back up work, share it and collaborate.

Your computer is not the only copy

So far your history lives only on your laptop. A remote is another copy of the repository hosted elsewhere, usually on GitHub. It is your backup, the place teammates fetch your work from, and the home of code review. The whole collaboration model is just two motions: push your commits up and pull theirs down.

your laptop  --git push-->  GitHub (origin)  <--git push--  teammate
your laptop  <--git pull--  GitHub (origin)  --git pull-->  teammate

Connecting a remote

git clone https://github.com/user/repo.git        # copy an existing repo

# or connect an existing local repo
git remote add origin git@github.com:user/repo.git
git remote -v
git push -u origin main       # first push; -u remembers the link

origin is just the conventional name of your main remote. Use SSH keys (or a credential helper) so you are not typing passwords.

Push, fetch and pull

git push                 # upload my commits
git fetch                # download others' commits without touching my files
git pull                 # fetch + merge (or rebase) into my branch
git pull --rebase        # keep history linear

If a push is rejected with "non-fast-forward", someone else pushed first. Pull, resolve anything needed, and push again.

The pull request workflow

  • 1. Update main (git pull) and branch off it.
  • 2. Commit your work, then git push -u origin feature/x.
  • 3. On GitHub, open a pull request (PR) from your branch into main.
  • 4. Teammates review, comment and request changes; automated checks (CI) run.
  • 5. Push more commits to the same branch to update the PR. When approved, merge it.
  • 6. Delete the branch and pull the updated main.

A good PR is small, has a clear title and description (what and why), and links the issue it solves. Reviewers can then respond in minutes instead of hours.

Forks

For open source projects you cannot push to, fork the repo (your own copy on GitHub), clone your fork, and open PRs from it. Keep it updated by adding the original as a second remote:

git remote add upstream https://github.com/original/repo.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main

GitHub CLI

gh auth login
gh pr create --fill              # open a PR from the current branch
gh pr checkout 123              # try someone else's PR locally
gh pr merge --squash

Publishing a project to GitHub, step by step

  • Create an empty repository on GitHub and copy its URL.
  • Connect your local project to it and give the connection the conventional name origin.
  • Push your branch, and set it up to track so later pushes are just git push.
$ git remote add origin git@github.com:ada/my-site.git
$ git remote -v
origin  git@github.com:ada/my-site.git (fetch)
origin  git@github.com:ada/my-site.git (push)

$ git push -u origin main
Enumerating objects: 3, done.
To github.com:ada/my-site.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Getting a copy of someone else's project

$ git clone https://github.com/ada/my-site.git
Cloning into 'my-site'...
$ cd my-site
$ git log --oneline   # the full history came with it

The pull request workflow, in plain steps

  • Branch: git switch -c fix-typo.
  • Commit your change and push the branch: git push -u origin fix-typo.
  • Open a pull request on GitHub: a page where teammates review, comment on and discuss your changes.
  • Update it by pushing more commits to the same branch if reviewers ask for changes.
  • Merge the pull request once approved, then delete the branch and git pull on main.

fetch versus pull

git fetch downloads new commits but does not touch your files, so you can look first (git log origin/main). git pull is fetch plus merge in one step. When in doubt, fetch first; it is always safe.

Key takeaways

  • A remote (usually origin on GitHub) is a shared copy of your repository.
  • git push sends your commits; git pull brings others' commits down.
  • git clone copies a whole repository with its history.
  • Pull requests are branches proposed for review before merging.
# Write your solution here
Up next · Lesson 5Undoing Things and Team WorkflowsRestore, reset, revert, stash and the reflog safety net.