Initializing a Repository
Every Git project begins its life either by initializing a brand-new repository in an existing (or empty) directory, or by cloning an existing repository from a remote. Initialization is the act of telling Git 'start tracking history in this folder' — it creates the hidden .git subdirectory that holds the entire object database, references, and configuration for that repository. Understanding what git init actually creates demystifies a lot of Git's behavior, because nearly every other Git command is really just reading from or writing to files inside that one directory.
Cricket analogy: A new franchise either sets up a brand-new academy from scratch or signs on to an existing league system with established records; git init is the former, standing up fresh infrastructure, while cloning joins an already-running competition.
Running git init
Running git init inside a directory creates a .git subfolder containing an empty object database, a HEAD file pointing at an unborn branch reference (typically refs/heads/main), and a default configuration file. At this point, no commits exist yet — the repository is initialized but empty. Any files already present in the directory are untracked; Git knows nothing about them until you explicitly git add them. You can also run git init <directory-name> to create and initialize a new folder in one step, and git init --bare to create a bare repository with no working directory, intended purely as a shared remote.
Cricket analogy: Setting up a brand-new academy creates an empty facility with a designated captain-in-waiting (like an unborn branch reference) but no players signed yet — equipment already on the grounds isn't officially rostered until you formally register each player, just like files aren't tracked until you git add them.
# Initialize a repo in the current directory
mkdir payments-service && cd payments-service
git init
# Initialized empty Git repository in /home/ada/payments-service/.git/
# Inspect what git init actually created
ls -la .git
# HEAD config description hooks/ info/ objects/ refs/
cat .git/HEAD
# ref: refs/heads/main
# Create a bare repository intended to be a shared remote (no working directory)
git init --bare payments-service.gitWhat's Inside .git
The objects/ directory is where blobs, trees, commits, and tags physically live, organized in subfolders named by the first two characters of their hash. refs/heads/ holds one file per local branch, each containing the commit hash that branch currently points to. HEAD is a special reference indicating which branch (or, in a detached state, which specific commit) you currently have checked out. config holds repository-local settings, and hooks/ contains sample scripts for hooking into Git events like pre-commit or post-receive.
Cricket analogy: A cricket board's archive organizes match records by year and format in labeled folders, a squad list holds one file per team pointing to its current captain, and the current playing-XI sheet notes which format is active, mirroring objects/, refs/heads/, and HEAD.
Deleting the .git directory does not touch your working files, but it permanently discards all history — the repository reverts to being an ordinary, untracked folder. This is occasionally used deliberately to 're-initialize' a project's history from scratch.
git init vs. git clone
git init creates a new, empty repository with no history and no remote configured. git clone, by contrast, copies an existing repository (including its full history) from a remote URL, automatically sets up a remote named origin pointing back to that URL, and checks out the default branch into a working directory. In practice, git init is used to start something brand new, while git clone is used to begin contributing to something that already exists elsewhere.
Cricket analogy: Founding a brand-new club starts with an empty trophy cabinet and no players signed, while joining an established franchise as a new recruit hands you its entire trophy history, current roster, and home ground automatically — that's git init versus git clone.
Running git init inside a directory that already contains a .git folder from a parent directory (a repository within a repository) creates a nested repository, which can lead to confusing 'files not showing up' behavior. Check with git rev-parse --show-toplevel before initializing to confirm you are not already inside a repository.
- git init creates the .git directory, which houses the object database, refs, HEAD, and configuration for a new, empty repository.
- A freshly initialized repository has no commits; existing files in the directory remain untracked until added explicitly.
- git init --bare creates a repository with no working directory, intended to serve as a shared remote.
- HEAD points to the currently checked-out branch (or a specific commit, in a detached state).
- git clone differs from git init by copying an existing repository's full history and automatically configuring an origin remote.
- Deleting .git discards all history but leaves working files untouched.
Practice what you learned
1. What does running `git init` in an empty directory create?
2. What is a key difference between `git init` and `git clone`?
3. What does the HEAD file inside .git typically reference?
4. What is the purpose of `git init --bare`?
5. What happens to your working files if you delete the .git directory?
Was this page helpful?
You May Also Like
What Is Git?
An overview of Git as a distributed version control system, its origin, design goals, and the core concepts that distinguish it from other tools.
The Git Object Model
A deep dive into how Git stores data internally as blobs, trees, commits, and tags — the content-addressable database underlying every Git operation.
Remotes Explained
A remote is a named reference to another copy of a repository, usually hosted elsewhere, that Git uses to synchronize commits, branches, and tags between machines.
Forking and Cloning
Cloning creates a full local copy of a repository's history, while forking creates a server-side copy under your own account — together they underpin how most open-source contribution happens.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics