Clone a repo and make your first change

You’re probably thinking: “So if there’s no giant download button, how do I actually get the files off GitHub?”

Well, look no further than the illustrious git clone command.

git clone: the real download button

When you find a repository on GitHub or GitLab, the main way to get it onto your computer is:

git clone <repo-url>

You get the URL from the green Code button on GitHub. Usually you copy the HTTPS URL, then run the command in your terminal.

Example:

git clone https://github.com/some-user/some-project.git

Git will create a new folder, download the project files, and also download the Git history behind those files. That history is the important part. You are not just downloading a random snapshot. You are downloading the repository as a Git project, with commits, branches, and a connection back to the remote repo.

That connection is usually called origin. You can check it with:

git remote -v

You’ll see something like:

origin  https://github.com/some-user/some-project.git (fetch)
origin  https://github.com/some-user/some-project.git (push)

That means your local repo knows where the remote repo lives.

What about downloading a ZIP?

GitHub and GitLab usually also let you download the project as a ZIP file. That works fine if you only want the files and do not care about Git.

But there is a catch: a ZIP download is not really a Git repo anymore. You do not get the commit history. You do not get the branches. You do not stay connected to the remote repository.

A ZIP is basically:

Give me the files as they look right now.

A clone is:

Give me the project, its history, and a connection back to where it came from.

So if you plan to work on the project, make commits, pull updates, or push changes back, use git clone. If you just want to look at the code once, a ZIP is fine.

Local branches vs remote branches

Once you clone a repo, you now have a local copy on your machine. But the repo on GitHub still exists too. That GitHub version is the remote repository.

Your machine has local branches, like:

main
feature/login-page

The remote has branches too, usually shown as:

origin/main
origin/feature/login-page

Those origin/... branches are called remote-tracking branches. A remote-tracking branch is Git’s local record of what the remote branch looked like the last time you synced with it.

That sounds weird, so here is the simpler version:

• main is your local branch.
• origin/main is your local snapshot of GitHub’s main.
• Git updates origin/main when you fetch or pull.
• You usually do not directly edit origin/main.

Remote-tracking branches are like Git saying:

Last time I checked GitHub, this is what their branch looked like.

git pull: update my branch now

Once you have the repo cloned, you’ll eventually want the newest changes from GitHub. That is where git pull comes in.

git pull

But, and I cannot stress this enough, git pull is not the same thing as a Pull Request. I know. Git did not make the naming easy.

git pull is not a Pull Request. A Pull Request is a GitHub or GitLab feature: a request to merge one branch into another. git pull is a Git command that updates your local branch with changes from the remote branch.

By default, running git pull does two things:

git fetch
git merge

First, Git downloads the newest remote information. Then it tries to merge those changes into your current local branch.

So when you run:

git pull origin main

You are basically saying:

Get the newest version of main from origin, then merge it into the branch I’m on.

You’ll usually run git pull when you start working, especially if you are on a team. That way you are not building on top of an old version of the code.

git fetch: update my knowledge, but do not touch my work yet

git fetch is similar to git pull, but safer and more chill.

git fetch

It contacts the remote repo and downloads information about new commits and branches. But here is the important part: git fetch does not merge those changes into your current branch. It only updates your remote-tracking branches.

So after a fetch, Git may update something like origin/main, but your local main branch stays exactly where it was.

That makes git fetch useful when you want to see what changed before bringing those changes into your work. A common workflow is:

git fetch
git status
git log --oneline main..origin/main

That lets you inspect the new commits before merging them.

Pull vs fetch

Here is the simplest way to remember it.

git fetch means:

Go see what changed on the remote, but do not change my branch yet.

git pull means:

Go see what changed on the remote, then bring those changes into my branch.

So fetch is look first. pull is look and update.

When you are new, git pull is usually what you want at the start of work. But as you get more comfortable, git fetch gives you more control, because it lets you inspect changes before merging them.

The mental model

Think of GitHub as the shared copy of the project. Your computer has your personal copy.

• git clone gets the project onto your computer for the first time.
• git fetch checks what changed on GitHub.
• git pull checks what changed and then updates your branch.
• A ZIP download just gives you the files, with none of the Git history or remote connection.

Once you understand that difference, GitHub stops feeling like a mysterious website full of buttons and starts feeling like what it actually is: a remote home for your Git project.