Cloning a Repository

Asha has put recipe-box on GitHub, and her brother Ravi wants to add his dal recipe. He does not need a zip file or a shared drive. One command gives him the whole project, with its complete history, ready to work in.

The rule

git clone copies the whole history and remembers where it came from as origin.

Every repository on a hosting service has a URL. Ravi passes it to git clone:

That one command:

1. Creates a folder named after the repository, recipe-box.
2. Downloads every commit and every branch, not just the latest files.
3. Records the source URL as a remote named origin.
4. Checks out the default branch, usually main, and links it to the remote's copy, origin/main, so later pushes and pulls know where to go.

Want a different folder name? Add it at the end:

URLs come in two main forms:

HTTPS works anywhere and asks you to sign in when you push (GitHub expects a token or a credential helper, not your account password). SSH uses a key pair you set up once, after which pushes need no typing. Either gives you the same repository.

Cloning and git init are the two ways a repository begins on your machine. git init starts a new, empty history; git clone starts from an existing one. Never run git init inside a folder you just cloned: it already is a repository.

The shortcut

Ask "Does this project already exist somewhere?" If yes, clone it. If no, git init it. Then, after cloning, check two things: git remote -v shows origin, and git log --oneline shows history you did not write.

The trap is downloading the ZIP file from the website instead. It contains the files but no .git folder: no history, no remote, and no way to send changes back.

Drills

Answer fast — trust the rule.

Remember

• git clone copies the whole history and remembers where it came from as origin.
• Existing project: clone it. New project: git init it.
• A ZIP download is files without history; clone instead.