AlgoInsight

Free lesson · Git Mastery

Creating a Repository (git init)

Easy7 min readgit

Creating a Repository (git init)

A note from Arun Selvam, Software Engineer at Apple iOS Frameworks.

When You Use This Command

git init is how you turn an existing folder into a Git repository. You use it when starting a brand-new project from scratch on your machine. If you're getting an existing project from somewhere else - GitHub, a colleague's machine, a server - you'd use git clone instead (Topic 2.2). The two commands cover most of the starting points.

The first time I ran git init was on a competitive programming practice folder in my second year at Anna University. I had about thirty Codeforces solutions in a folder called cp-practice. I wanted to track which problems I'd solved and when, and I'd just learned that Git existed. I cd'd into the folder, typed git init, hit enter, and watched nothing visible happen. The terminal printed one line and gave me back the prompt. That was it. No new visible folders, no obvious change. I genuinely thought it had failed.

It hadn't. This topic explains what actually happened in that silent moment.

What git init Does

The command is simple:

git init

This command initializes a new Git repository in the current directory. Run it inside a folder you want to track. Git creates a hidden subfolder called .git inside the current directory and prints a confirmation line. The rest of the folder's contents are untouched.

After running it, you'll see output like:

Initialized empty Git repository in /home/you/projects/myproject/.git/

The path at the end is the location of the new .git folder - Git's metadata directory. Everything Git tracks about your project lives inside that one hidden folder. Module 14 covers what's in there in detail; for now, the relevant fact is that it exists and you should not edit it directly.

What You Don't See

The .git folder is hidden by default on most systems. On macOS and Linux, folders starting with a dot are hidden from ls unless you use ls -a:

ls          # files only
ls -a       # files including hidden ones

The first command lists visible files only. The second includes hidden files - anything starting with a dot. After git init, running ls dash a shows a new .git folder alongside whatever else is in the directory. The dot prefix is the Unix convention for hidden files; it's not a Git-specific choice.

In Windows, .git is similarly hidden by default in File Explorer; toggling "show hidden items" in the View tab reveals it.

If you look inside the .git folder, you'll see structure like:

.git/
├── HEAD
├── config
├── description
├── hooks/
├── info/
├── objects/
└── refs/

This is the initial structure of a fresh Git repository's metadata. HEAD is a reference to the current branch. Config is the repository-local Git configuration. Description is unused for most workflows. The hooks folder holds scripts that run at specific Git events - Module 15 covers them. The info folder holds repo-local exclude patterns. Objects and refs are where Git stores commits, file snapshots, and branch pointers. Module 14 covers the internals in depth.

Do not edit anything inside .git directly. The whole point of Git's user-facing commands is that you don't have to. Module 14 covers what's inside for the curious, but for daily work, treat .git as opaque.

Running git init Inside an Existing Project

git init works on a folder whether or not it already has files. Running it on an existing project doesn't change any of the project's files - it just adds the .git folder. The project's existing contents are still there afterward, unchanged.

This is how I added Git to my Codeforces practice folder. Thirty .cpp files already in the directory, none under version control. I ran git init in that folder, and the files stayed exactly where they were. None of them was tracked yet - Git knew about the folder being a repository but didn't yet know about the files (Topic 2.3 covers why). Adding them came next.

Creating a Folder and Initializing It in One Step

A common pattern is creating a new project folder and immediately initializing Git inside it:

mkdir new-project
cd new-project
git init

This is the standard pattern for starting a new project. Make a directory, change into it, then initialize Git. Three commands, all run from the parent folder you want to create the project under. After this, new-project exists, contains a .git folder, and is ready for you to start adding files.

A shorter form is git init <directory-name>, which creates the folder and initializes it in one step:

git init new-project

This creates a folder called new-project in the current directory and initializes a Git repository inside it. After running, the .git folder exists inside new-project. Note that your terminal's working directory does not change; you're still in the parent folder. Use cd new-project to enter it.

I used to type out the three-command form by habit; the one-command form is slightly faster once you remember it exists.

What git init Doesn't Do

git init does a small number of specific things. It does not:

This is the right place to remind you of the model from Topic 1.1 - Git is a local program. git init runs entirely on your machine and doesn't need a network connection.

When NOT to Use git init

If you're getting an existing project from somewhere, don't use git init. Use git clone (Topic 2.2). A common newcomer mistake is to download a project as a ZIP file, extract it, and then run git init inside the extracted folder. This creates a brand-new repository with no connection to the original project's history. The original's commits, branches, and authors are not part of your local repository.

If you actually want the project's history, clone it instead.

Bare Repositories

There's a variant called a bare repository:

git init --bare myproject.git

The dash dash bare flag creates a repository without a working directory. Bare repositories are used as the server-side storage that other clones push to and fetch from. They have no checked-out files - the entire folder is just the contents of what would normally be the .git directory. You'd never use a bare repository directly for editing; it exists to be pushed to and cloned from. By convention, bare repository folders end in .git.

Bare repositories are mostly used for self-hosted Git servers. If you use a hosting service like GitHub or GitLab, you'll rarely create one yourself; the service manages them. For all practical purposes in this course, git init without --bare is what you'll use.

A Practical Story

On my third week at Apple, my manager asked me to look at a small data-processing script another engineer had written and improve it. I cd'd into the script's folder on my laptop - about ten Python files, scattered across two subdirectories. There was no Git history because the original engineer had never initialized a repository there. The first thing I did, before reading any code, was git init and git add . and git commit -m "initial import". From that point on, every change I made was tracked. When I broke something later and needed to compare against the original, the history was there.

The pattern I picked up from that moment: anytime I'm about to modify a folder of files I didn't create, git init is my first action. Even if nobody else will ever see the repository, the local history lets me experiment safely.

What Comes Next

Topic 2.2 covers git clone - getting an existing repository onto your machine. Topic 2.3 explains the staging area, which is the next concept after a repository exists. Topic 2.4 shows how to actually start tracking files with git add.

The basic workflow you'll learn over the next few topics: init or clone → add → commit. This pattern is the foundation of every Git interaction.

What Goes Wrong

Warning: Common git init mistakes:

Running git init inside an existing repository. Git will print a message warning that the repository already exists. The existing one is preserved; nothing harmful happens, but the message can confuse you. Check with git status first if you're unsure.

Running git init on a project that should have been cloned. You'll have a repository, but with no connection to the original. Delete the .git folder you just created and use git clone (Topic 2.2) instead.

Running git init in your home directory. Possible but almost never what you want. The repository would try to track every file under your home directory, including system folders. If you do this accidentally, delete the ~/.git folder.

Expecting files to be tracked automatically. They aren't. After git init, git status shows your files as "untracked" until you git add them.

Initializing nested repositories. Running git init inside a folder that's already inside another Git repository creates a sub-repository. This is usually a mistake; you probably wanted to add files to the outer repo. Module 15.2 covers submodules, which is the deliberate version of nested repos.

Editing .git/ directly. Don't. The user-facing Git commands are the supported interface. Editing internal files can corrupt the repository.

Try It

Exercise: Practice creating repositories:

  1. Create a new empty folder called my-first-repo and git init inside it. Run ls -a and confirm the .git folder exists.
  2. Look at the contents of .git/HEAD with cat .git/HEAD. Note what's there. Topic 14.5 will cover what it means.
  3. Create a second folder by running git init another-project in one command. Notice that your working directory doesn't change.
  4. Delete the .git folder from one of these repositories with rm -rf .git. Run git status - Git will tell you the folder is no longer a repository.
  5. Inside an existing folder you have (notes, recipes, anything), run git init. The folder is now a repository. The existing files are untracked, ready for you to git add them in the next topic.
  6. Look at the .git/config file with cat .git/config. Note that the local repository config exists separately from your global config (Topic 1.7).

Back to Git Mastery