git init: turn a folder into a repository

git init turns an ordinary folder into a repository: it creates a hidden .git directory inside, and that is where the whole history of the project will live.

You run this once per project, at the very start. Go into the folder with your files (or make an empty one) and run:

$ mkdir my-first-repo
$ cd my-first-repo
$ git init
Initialized empty Git repository in /home/anna/my-first-repo/.git/

One line of output, and the directory is a repository. Nothing changed on the outside: your files stay where they were, and git neither touches nor rewrites them.

What appeared in .git

Names that start with a dot are hidden from the file manager and from a plain ls. The -a flag turns that off:

$ ls -a
.  ..  .git
$ ls .git
HEAD  config  description  hooks  info  objects  refs

The objects directory is the snapshot store, where the content of every version of every file ends up. HEAD is the pointer to your current place in the history. refs holds branches and tags, and config holds the settings of this particular repository. You do not need to go in there by hand: everything inside is changed by commands.

Delete .git and you delete the whole history, with no trash bin. The project files survive, but they become just files.

init versus clone

git init starts an empty history for a project that is not in git yet. git clone takes an existing repository from a server together with its whole history and creates the folder for you. You do not run init after clone, which is a common first-day mix-up.

Running git init again in the same directory breaks nothing and erases no history:

$ git init
Reinitialized existing Git repository in /home/anna/my-first-repo/.git/

Common mistakes

The most common one is running git init in your home directory or straight on the desktop. Git obeys and starts treating everything as project content: downloads, screenshots, unrelated folders, application caches. A repository belongs to one specific project, in its own folder.

If you already did it, nothing terrible happened. Use pwd to confirm you are standing in the folder where the stray git init happened, then remove the directory:

$ pwd
/home/anna
$ rm -rf .git

Your files stay put. Check the path twice: rm -rf asks nothing.

The second mistake is running git init inside an existing repository, in a subfolder. It is allowed, but you get a nested repository that the outer one does not track, and changes inside it silently stay out of your commits.

Where this is in the book

The topic is covered in Chapter 2. Your first repository.

To practise it by hand, take the interactive lesson Your first repository.