git init: Creating Your First Repository

What is git init?

Every Git repository starts with a single command: git init. It tells Git to start tracking changes inside the current folder. Under the hood, it creates a hidden.git directory that stores everything Git needs: your commit history, branch pointers, configuration, and the object database that holds every version of every file you have ever committed.

Without git init (or git clone, which runs it for you), a folder is just a folder. Git has no knowledge of it and no way to track changes. Running the command is a one-time setup step that transforms a plain directory into a fully functional version-controlled repository.

Think of git init as pressing the record button. Nothing is captured yet, but from this point on Git is ready to track every change you tell it about.

Creating your first repo

The most common workflow is to create a new project folder, navigate into it, and then initialize Git. Follow the three steps below to create your first repository from scratch.

That is all there is to it. You now have a fully operational Git repository. The .git directory was created automatically and your default branch (usually main) is ready for commits.

If you already have project files in an existing folder, you can skip the mkdir step and simply run git init inside that folder. Git will not modify any of your existing files.

What's inside .git?

You do not need to memorize the contents of the .git directory, but understanding the basics helps demystify how Git works. Here is what you will find inside a freshly initialized repository:

.git/
  HEAD            # Points to the current branch (e.g. refs/heads/main)
  config          # Repository-level configuration
  description     # Used by GitWeb; you can usually ignore this
  hooks/          # Client- and server-side hook scripts
  info/           # Global exclude patterns
  objects/        # All content — blobs, trees, commits, tags
  refs/           # Branch and tag pointers
    heads/        # Local branches
    tags/         # Tag references

The two most important pieces are objects/ and refs/. The objects folder is Git's content-addressable database. Every file, directory snapshot, and commit you create is stored here as a compressed object identified by its SHA-1 hash. The refs folder holds pointers (branches and tags) that give human-readable names to specific commits.

The HEAD file tells Git which branch you are currently on. If you open it in a text editor right after git init, you will see something like ref: refs/heads/main.

Golden rule: never manually edit files inside .git unless you know exactly what you are doing. Let Git manage it for you.

Your first commit

An empty repository is not very useful. Let's create a file, stage it, and make your first commit. This two-step process — stage then commit — is the fundamental Git workflow you will repeat hundreds of times.

Let's break down each command. First, git add:

And then git commit:

After running these commands, Git has stored a permanent snapshot of your README.md file. You can change or even delete the file, and Git will still be able to restore this exact version at any point in the future.

Understanding the output

The output [main (root-commit) a1b2c3d] tells you three things: the branch (main), that this is the very first commit in the repository (root-commit), and the abbreviated SHA hash (a1b2c3d) that uniquely identifies this commit.

Doing it visually with Komitly

While the terminal is powerful, a visual Git client like Komitly makes it easier to understand what is happening. Instead of reading text output, you see your commit history as an interactive graph, and staging files is as simple as clicking a checkbox.

Here is what a small repository looks like after a few commits in Komitly's commit graph:

Each circle represents a commit. The branch label main shows you exactly where the branch pointer is. You can click on any commit to see the full diff, the author, and the timestamp.

When you are ready to make a new commit, the staging panel shows you exactly which files have changed and lets you move them between staged and unstaged with a single click:

Try clicking the files above to move them between the staged and unstaged sections. In the real app, you can also stage individual lines or hunks within a file, giving you fine-grained control over exactly what goes into each commit.

Common mistakes

Even experienced developers trip over these from time to time. Here are the most common pitfalls when initializing a Git repository:

• Running git init in the wrong directory. If you accidentally initialize Git in your home folder or a parent directory, every file underneath becomes part of the repo. Always cd into your project folder first and double check with pwd.
• Forgetting to create a .gitignore file. Without a .gitignore, you risk committing build artifacts, node_modules, or sensitive files like .env. Create one before your first commit.
• Initializing inside another Git repo. Nested Git repositories cause confusing behavior. Before running git init, run git rev-parse --git-dir to check if you are already inside a repo.
• Not making an initial commit. Some commands like git branch do not work until there is at least one commit. Always create an initial commit right after initializing.
• Confusing git init with git clone. Use git init when starting a brand new project. Use git clone when you want a copy of an existing remote repository.

Summary

git init is the first command in every Git project. It creates the hidden .git directory that gives Git everything it needs to start tracking your files. Here is a quick recap of what we covered:

• git init creates a new, empty Git repository in the current directory.
• The .git folder contains objects (your file snapshots), refs (branch and tag pointers), and configuration.
• After initializing, you stage files with git add and save snapshots with git commit.
• A visual tool like Komitly lets you see your commit history as a graph and stage files with a click instead of typing commands.
• Always create a .gitignore and make an initial commit right after running git init.

With your repository initialized and your first commit saved, you are ready to start building. Next, learn how to save your work effectively with git commit.