LearnAI ToolsCareerPractice BuildsPlayDevelopmentContact
Lesson 1016 min read

Remote Repositories and GitHub: push, pull and clone

Create a repository on GitHub, connect it to your local project, push your commits, clone a repository, and keep copies in sync with fetch and pull.

Git & GitHub learning pathLesson 10 of 16
View course
On this page 12 sections

Introduction

Until now, Priya’s portfolio has lived only on her laptop. If the laptop dies, the history dies with it, and nobody else can see or contribute to her work. Hosting the repository on GitHub gives her an off-site backup, a public portfolio of her code, and the basis for collaboration.

What You Will Learn
  • What a remote is and what origin means.
  • How to create a GitHub repository and push your project to it.
  • How to clone a repository to another computer.
  • How fetch and pull keep your copy up to date.

What Is a Remote?

A remote is a copy of your repository stored somewhere else — usually on GitHub — that you can send commits to and get commits from. Your local repository remembers remotes by name. By convention, the main remote is called origin. Four commands do almost all the work:

CommandDirectionWhat it does
git pushLocal → remoteUploads your new commits
git fetchRemote → localDownloads new commits but does not change your files or branches
git pullRemote → localFetches, then merges the new commits into your current branch
git cloneRemote → new folderDownloads an entire repository with its full history

Create a Repository on GitHub

  1. Sign up for a free account at github.com if you have not already, and verify your email.
  2. Click the + icon in the top-right corner and choose “New repository”.
  3. Enter a name (Priya uses my-portfolio) and choose Public or Private.
  4. Leave “Add a README”, “.gitignore” and “license” unticked — your local project already has history, and an empty repository is easiest to push into.
  5. Click “Create repository”. GitHub shows the repository’s URL and the commands to push an existing project.

Connect and Push

Back in the terminal, inside the project, add the GitHub repository as a remote called origin (use your own URL):

git remote add origin https://github.com/priya-sharma/my-portfolio.git
git remote -v
Output

Click Run to see what this code prints.

Each remote has a fetch URL and a push URL, which are usually the same. Now push the main branch:

git push -u origin main
Output

Click Run to see what this code prints.

The first time, Git asks you to sign in — the next lesson covers how. You may also see progress lines such as “Enumerating objects” and “Writing objects”; they are just Git reporting its progress. -u (short for --set-upstream) links your local main to origin/main, so from now on a plain git push or git pull knows where to go:

git status
Output

Click Run to see what this code prints.

Refresh the repository page on GitHub and you will see all of Priya’s files and her full commit history.

Mini Challenge · Predict the Output

You ran git push -u origin main once. Later you commit again and run just git push. What happens?

Choose one answer

Cloning a Repository

git clone downloads a complete repository — every file and every commit — into a new folder, and sets up origin automatically. Priya clones her portfolio onto her second laptop (the folder name at the end is optional; without it, Git uses the repository name):

git clone https://github.com/priya-sharma/my-portfolio.git laptop-copy
Output

Click Run to see what this code prints.

On that laptop, she improves the About section and pushes:

cd laptop-copy
git commit -am "Mention accessibility in about section"
git push
Output

Click Run to see what this code prints.

The line c7a0141..fa73bf0 main -> main shows the remote main moving from one commit to the next.

Fetch: See What Changed

Back on her main computer, Priya’s copy does not know about the new commit yet — Git never contacts the remote unless you ask. git fetch downloads new commits into remote-tracking branches like origin/main, without touching your files or your own branches:

git fetch
Output

Click Run to see what this code prints.

git status
Output

Click Run to see what this code prints.

Fetching first is a safe way to look before you leap. To see exactly which commits are on the remote but not in your branch, compare the two:

git log --oneline main..origin/main
Output

Click Run to see what this code prints.

Pull: Bring Changes In

git pull fetches and then merges the upstream branch into your current branch:

git pull
Output

Click Run to see what this code prints.

Both computers now have identical history. git branch -vv shows each local branch, its upstream, and whether it is ahead or behind:

git branch -vv
Output

Click Run to see what this code prints.

Mini Challenge · Put It in Order

Put a typical day of working with GitHub in order.

  1. git push to upload your commits
  2. git pull again to pick up anything new before sharing
  3. Edit files and make commits
  4. git pull to get everyone’s latest commits

When a Push Is Rejected

If someone else pushed to the same branch since your last pull, Git refuses your push with a message like “Updates were rejected because the remote contains work that you do not have locally”. This protects their work. The fix is to pull first (resolving any conflict as in lesson 8), then push again. Never use --force to get around it on a shared branch — that would delete their commits from GitHub.

When both you and the remote have new commits, git pull has to combine them. If you skipped the pull.rebase setting from lesson 2, recent versions of Git stop with “fatal: Need to specify how to reconcile divergent branches” and list your options. Run git config --global pull.rebase false to merge (or true to rebase, lesson 9), then pull again. The Team Collaboration project on the course page walks through this situation end to end.

Common Mistakes

Avoid These Mistakes
  • Creating the GitHub repository with a README, then being unable to push because the histories differ — start with an empty repository, or pull first.
  • Forgetting to push, so your work exists only on one computer.
  • Starting work without pulling, then hitting conflicts that could have been avoided.
  • Force-pushing to “fix” a rejected push and wiping out a teammate’s commits.

Frequently Asked Questions

origin is the remote (the repository on GitHub). origin/main is your local record of where that remote’s main branch was the last time you fetched. It only updates when you fetch, pull or push.

Yes. GitHub’s free plan includes unlimited public and private repositories.

Yes. You might push to both GitHub and GitLab, or, when contributing to open source, use origin for your fork and upstream for the original project (lesson 13).

pull is fine for everyday work on your own branch. Use fetch when you want to see what changed before merging it, or when you are not sure what is on the remote.

Key Takeaways

  • A remote is another copy of the repository; origin is the conventional name for the main one.
  • git remote add origin <url> connects a local project; git push -u origin main uploads it and sets the upstream.
  • git clone copies a whole repository, including history, and sets up origin.
  • git fetch downloads without changing your work; git pull fetches and merges.
  • If a push is rejected, pull first, resolve any conflicts, then push.

Summary

Priya’s portfolio is on GitHub and in sync across two computers. When she pushed, Git asked her to sign in — and since GitHub no longer accepts account passwords for Git, the next lesson shows the two proper ways to authenticate: HTTPS with a credential manager or token, and SSH keys.

Next Lesson →

Connecting to GitHub: HTTPS Tokens and SSH Keys