Git for Beginners
by Sergey Okinchuk
Your First PushStaying In Sync
Cloning Someone Else's Repository
Topic 31

Cloning Someone Else's Repository

GitHub

Pushing sends a repository to GitHub. Cloning is the other direction: take a repository that exists there and make a complete copy on your machine.

It is how you start every job, every tutorial and every open-source contribution for the rest of your career, and it is one command.

Doing it

Copy a repository onto your machine
git clone git@github.com:YOUR-USERNAME/sandpiper.git
cd sandpiper

Git creates a folder named after the repository, downloads everything into it, sets origin to where it came from, and puts you on the default branch.

That is three of the things you did by hand two topics ago, done for you. There is no git init and no git remote add after a clone; running them would only create confusion.

You get the whole history

A project you have never seen, and its entire past
git log --oneline

Every commit is there, not just the current files. Which means git blame and git show from Chapter 3 work immediately on code you have never seen — the four questions from the first page of this book are answerable about someone else's project the moment the clone finishes.

It is also why cloning a long-lived project can take a surprising amount of time and disk space. You are downloading years of history, not a folder.

Cloning does not give you write access

Anyone can clone a public repository. What you can then do is read it, run it, and commit to your own copy as much as you like.

What you cannot do is push back, unless the owner has given you access. Try, and GitHub refuses. That is not a bug and not a discouragement — it is exactly how open source is supposed to work, and the route around it is a fork, which is Chapter 9.

What clone sets up for you in one command
A repositoryon GitHub
→
git cloneone command
→
A full local copyhistory · origin · ready to work

SSH or HTTPS

GitHub offers two URL forms for every repository, and they match the two mechanisms from earlier in this chapter. Use the SSH form if you set up a key, the HTTPS form if you set up a token.

Cloning a public repository over HTTPS needs no credentials at all, which is why a stranger's project clones without any setup. Pushing is where the mechanism matters.

Your own project on another machine

Clone is also how you get your own work onto a second computer, and it is the answer to "how do I carry on at home". Clone, work, commit, push. The copies stay in step through the loop in the next topic.

It is what Theo will run in Chapter 8, from his own laptop, to get Sandpiper. From Git's point of view there is nothing to distinguish his copy from yours.

Common Confusions
  • "Clone downloads the current files." It downloads the repository, history included. That is why a clone of a long-lived project can be much larger than the files you can see.
  • "I need to run git init after cloning." The clone is already a repository with its remote configured. Running init inside it is a good way to create a confusing mess.
  • "I can push to anything I clone." Reading is open on a public repository; writing needs access from the owner. The polite route around that is Chapter 9's fork.
  • "Cloning my own repository twice creates two different projects." Both copies are complete repositories pointing at the same origin. Keeping them in step is the next topic.
Why It Matters
  • Clone is the first command you run in any new job, and the fact that it configures origin for you is why nobody teaches git remote add until they need it.
  • Getting the whole history is what makes blame and show work on an unfamiliar codebase — the investigative loop from Chapter 3, applied to someone else's project.
  • Understanding that reading is open and writing is not sets up the fork workflow in Chapter 9 as an obvious solution rather than an odd ritual.

Knowledge Check

What does git clone set up that you would otherwise do by hand?

  • The folder, the full history, and origin pointing at where it came from
  • The folder and the current files, leaving the remote to be added afterwards
  • A connection to GitHub that keeps the copies synchronized automatically
  • A branch for your own work, so the original branch is never modified

You clone a stranger's public project and commit a fix. Can you push it?

  • No, since pushing needs the write access that the owner has not given you
  • Yes, because cloning a public repository grants write access to everyone
  • Yes, but only to a branch you created yourself rather than to main
  • Only after the owner reviews the commit and approves it on the website

Why can a clone of a long-lived project be surprisingly large?

  • Because it downloads the whole history, not only the files that you can see
  • Because Git stores several copies of every file for redundancy on your disk
  • Because the download includes the project's issues and pull request discussions
  • Because clone downloads every branch as a separate complete copy of the project

Which of the four questions from Chapter 1 can you answer about a project you cloned five minutes ago?

  • All four of them, because the entire history came down with the clone
  • None, because the history belongs to the original author and is not shared
  • Only what changed, since messages and authors are stripped when a repository is copied
  • Only the most recent ones, because older history is fetched on demand later

You got correct