Initialising and Cloning Repositories

A Git repository is where your project lives under version control — it is the container that holds your files, your entire commit history, your branches, and all the metadata Git needs to track changes over time. Before you can start using Git on a project, you need a repository.

There are two ways to get one: create one from scratch with git init, or copy an existing one with git clone.

What Is a Repository?

A repository (often shortened to repo) is a directory that Git is tracking. The moment you initialise or clone a repository, Git creates a hidden .git folder inside it. That folder contains everything Git needs — the object database, the commit history, branch references, configuration, and more.

The files you actually work with live outside .git in the working directory. Git watches the working directory and compares it against what is stored in .git to determine what has changed.

If you ever delete the .git folder, Git loses all history and tracking — your files remain, but the repository is gone.

Creating a Repository — git init

git init turns any existing directory into a Git repository. It does not matter whether the directory is empty or already has files in it.

Starting a brand new project

mkdir my-project
cd my-project
git init

Output:

Initialized empty Git repository in /home/wariz/my-project/.git/

Git creates the .git folder and the repository is ready. At this point, no files are tracked yet — the repository exists but its history is empty.

Adding version control to an existing project

If you have a project that already has files but is not yet under version control, navigate to its directory and run git init:

cd /path/to/existing-project
git init

Git creates the .git folder but does not automatically track any of the existing files. You still need to stage and commit them to begin recording history:

git add .
git commit -m "Initial commit"

After this first commit, all the files you staged are now tracked and recorded in Git's history.

What git init creates

Running git init produces the following structure:

my-project/
├── .git/
│   ├── HEAD
│   ├── config
│   ├── objects/
│   └── refs/
├── (your project files)

The .git folder is hidden by default on macOS and Linux. The repository is fully self-contained — everything Git needs is inside it.

Cloning a Repository — git clone

git clone copies an existing repository from a remote source — typically a URL on GitHub, GitLab, or another hosting platform — onto your local machine. Unlike checking out a file from a centralised system, cloning gives you a complete copy of the entire repository, including every commit, every branch, and the full project history.

Basic syntax

git clone <url>

Example

git clone https://github.com/facebook/react

This creates a react directory in your current location, initialises a .git folder inside it, downloads all the repository data, and checks out the latest version of the default branch. You end up with a fully functional local copy of the project ready to work with.

Cloning into a custom directory name

By default, git clone names the local directory after the repository. To use a different name, pass it as a second argument:

git clone https://github.com/facebook/react my-react-copy

This clones the repository into a folder called my-react-copy instead of react.

What cloning actually does

When you run git clone, Git:

1. Creates a new directory with the repository name (or your custom name).
2. Initialises a .git folder inside it.
3. Downloads all objects — every file version, every commit, every branch — from the remote.
4. Creates a remote reference called origin pointing back to the URL you cloned from.
5. Checks out the latest version of the default branch into your working directory.

Because you receive the full history, you can work entirely offline after cloning. You can browse history, create branches, and make commits without any network connection. You only need the network when you push changes back or pull new ones down.

Clone vs. checkout

If you are familiar with older version control systems like Subversion, the distinction matters. In SVN, "checkout" gives you a working copy of the current files — not the history. In Git, cloning gives you everything: the current files and the entire history of the project. This is a fundamental difference and one of Git's core advantages.

Transfer Protocols

When cloning from a remote, Git supports several protocols for the connection:

For most developers, HTTPS is the starting point — it works immediately without any additional setup. SSH is worth configuring once you are working regularly with a platform, as it removes the need to enter credentials on every push.

git init vs. git clone — When to Use Which

In practice, git clone is used far more frequently than git init. Most of the time you are either joining an existing project or continuing work you have already started — both of which involve cloning. git init is primarily for when you are the one starting something new.

A Complete Setup Example

Here is what starting a new project from scratch looks like end to end:

# Create the project directory and initialise Git
mkdir winehouse-labs-site
cd winehouse-labs-site
git init

# Create some initial files
touch README.md index.html

# Stage and commit the first snapshot
git add .
git commit -m "Initial project setup"

# Verify the repository is clean
git status
# On branch main
# nothing to commit, working tree clean

And here is what joining an existing project looks like:

# Clone the repository
git clone https://github.com/winehouse/campus-access

# Move into the project directory
cd campus-access

# Check the status — all files are tracked and unmodified
git status
# On branch main
# nothing to commit, working tree clean

Summary