Clone a Repository & Manage Remotes

You've just been handed a URL to a repository that holds weeks of work — and your first instinct is to copy the whole thing onto your machine. But if you treat git clone as just "download a folder", you'll miss the invisible thread that ties your local copy to the remote, and that thread — the remote — is what makes collaboration, updates, and code review possible. In this lesson, you'll learn to clone any repository with confidence, then manage the remotes that keep your local work in sync with the wider world.

The problem this lesson solves

Imagine you join a team that stores its code on GitHub, GitLab, or Bitbucket. You need your own copy to edit, test, and commit — but the centralized "shared folder" approach fails the moment two people edit the same file. Git solves this with distributed version control: every clone is a full repository with its own history, branches, and tags. The problem is that without a clear understanding of remotes, you'll either push to the wrong place, pull from a stale source, or lose track of which URL is authoritative.

Playing with a real project is the fastest way to learn Git, and cloning an existing repo is the door to that world. It's also the first step in contributing to open source: you clone, create a branch, make changes, and open a pull request. If you skip this lesson, you'll flounder with phrases like "origin/main" and "upstream", and you'll likely break your own workflow.

Core concept / mental model

Think of a Git repository as a living document living in two places: your local machine and a remote server. The remote is simply a URL that points to another copy of the repo. When you clone, Git:

• Copies the entire repository history (all commits, branches, tags) to your local disk.
• Creates a hidden directory .git that holds all that metadata.
• Sets up a default remote called origin that points back to the source.
• Checks out a default branch (often main) so you have a working copy.

A useful image: the remote is the post office, your local repo is your mailbox, and commands like fetch, pull, and push are the mail carriers. clone is how you get a new mailbox that's already subscribed to the post office.

Key terms you'll meet: - origin — the default remote; think of it as the "original" repo you cloned from. - fetch — downloads new commits from the remote but doesn't change your working files. - pull — fetches and then merges (or rebases) into your current branch. - push — uploads your local commits to the remote. - upstream — the original repo you forked from, if you're contributing to open source.

How it works step by step

1. Cloning a repository

The magic command is git clone <url>. Git will:

1. Resolve the URL (HTTPS or SSH).
2. Download all objects (commits, trees, blobs) into a new directory named after the repo.
3. Create a refs/remotes/origin/ namespace with remote-tracking branches.
4. Check out the default branch into a working tree.

You can customize the target directory: git clone <url> my-custom-dir.

2. Viewing your remotes

git remote -v shows the URLs for each remote. You'll typically see origin twice (fetch and push). It's your first diagnostic command whenever something feels off.

3. Adding and removing remotes

Sometimes you need to connect to a second remote — for example, to a teammate's fork. Commands: - git remote add <name> <url> - git remote remove <name> - git remote rename <old> <new>

4. Synchronising with a remote

• git fetch origin — updates your remote-tracking branches, no file changes.
• git pull origin main — fetch + merge into your current branch.
• git push origin main — push your local commits to the remote.

The -u flag sets the upstream when you first push a new branch: git push -u origin my-branch.

5. Inspecting remote branches

git branch -r lists remote-tracking branches (e.g., origin/main). git show origin/main shows the tip of that branch.

Hands-on walkthrough

Let's make this concrete. We'll use a small public repo so you can follow along with zero setup beyond Git.

Example 1: Clone and inspect remotes

# Clone a real, tiny repo (the Git official docs also work)
git clone https://github.com/octocat/Hello-World.git
cd Hello-World

# See the remote URL
$ git remote -v
origin  https://github.com/octocat/Hello-World.git (fetch)
origin  https://github.com/octocat/Hello-World.git (push)

# List remote branches
git branch -r
  origin/HEAD -> origin/main
  origin/main

Expected output: remote-tracking branches show under origin/. You can now git log --oneline to see the full history locally.

Example 2: Add a second remote and fetch it

# Add the official Git repo remote as 'upstream' (if you forked it)
git remote add upstream https://github.com/git/git.git

# Fetch commits from the upstream without changing your files
git fetch upstream

# You now have a local copy of upstream's branches
git branch -r | grep upstream
  upstream/main

Example 3: Rename and change a remote URL

# Rename origin to 'github'
git remote rename origin github

# Change the URL if you moved hosts or switched to SSH
git remote set-url github git@github.com:yourname/yourrepo.git

# Verify
git remote -v

Pro tip: Always use git remote -v after any change to confirm what you intended. A single typo in a URL can send your pushes into the void — and into the logs of a busy server.

Compare options / when to choose what

HTTPS vs SSH

When to choose: If you're a solo dev working on GitHub, HTTPS with a token is fine. If you're on a team or want convenience, SSH keys are worth the one-time setup. In a CI pipeline, HTTPS with a secret token is the standard.

git clone vs git init + git remote add

Clone is almost always the right entry point when the repo already exists. If you have a local project and need to push it to a new remote, git init + git remote add is your friend.

fetch vs pull

• fetch is non-destructive; it only updates remote-tracking refs.
• pull = fetch + merge into your current branch — it can cause merge conflicts.

Use fetch when you want to inspect changes before integrating them, for example in a shared branch.

Troubleshooting & edge cases

1. Permission denied (publickey)

When using SSH, your key might not be loaded. Fix: add it to the agent or verify with ssh -T git@github.com. With HTTPS, ensure your token has the repo scope.

2. Repository not found

This can mean the URL is wrong, the repo is private, or you don't have access. Double-check the URL, and if private, use a token or add your SSH key to the account.

3. remote: Repository not found after a clone with a typo

Use git remote set-url origin to correct the URL — no need to re-clone.

4. fatal: refusing to merge unrelated histories

This happens when you try to pull from a remote that has commits your local repo doesn't share. Use git pull origin main --allow-unrelated-histories only if you truly want to merge two independent histories — e.g., you started from an empty repo.

5. Accidentally cloned into a subdirectory

If you didn't specify a directory and the folder already exists, Git will clone into that folder but may fail if it's not empty. Delete or move the empty folder and re-clone, or clone with a different target name.

6. origin has a stale URL

Use git remote -v to see it, then git remote set-url origin <new-url> to correct it. This is common when you switch from HTTP to SSH.

Pro tip: Before you push, always run git pull --rebase (or git fetch and inspect) to avoid messy merge commits. --rebase replays your local commits on top of the remote's, keeping history linear.

What you learned & what's next

You've now turned the mystery of git clone into a repeatable ritual: you can clone any repository, inspect and manage its remotes, fetch and pull from multiple sources, and fix the most common remote-related errors. You've learned the difference between fetch and pull, the role of origin and upstream, and how to choose between HTTPS and SSH.

Key takeaways: - git clone creates a full local copy with a default remote named origin. - git remote -v shows all remotes and their URLs. - Add, rename, and remove remotes with remote add, remote rename, and remote remove. - fetch is safe; pull merges; push uploads. - HTTPS + token is fine for single devs; SSH is better for teams and frequent work.

Next in the Git Tutorial: You're ready to master branching and merging. Now that you can clone and sync, you'll learn how to juggle multiple lines of work, resolve merge conflicts, and keep your history tidy. Tackle the next lesson to become a truly collaborative Git user.