Turning a Folder Into a Repository
Topic 06

Turning a Folder Into a Repository

Core

Sandpiper currently has the same status as every other folder on your machine: none. Git has never heard of it. One command changes that.

git init tells Git to start paying attention to a folder. It creates one hidden directory inside it, changes nothing else, and from that moment the folder can have a history.

Running it

Open a terminal, move into the project folder, and run the command:

Turn the Sandpiper folder into a repository
cd sandpiper
git init

Git answers with something like Initialized empty Git repository in /Users/you/sandpiper/.git/. Note the word empty: it is being honest with you. Nothing has been recorded.

What a repository is

A repository is a folder Git is tracking, plus the hidden .git directory that holds every version it has recorded. Everyone shortens it to repo in conversation, and this book will too.

Your files did not move and nothing about them changed. index.html is exactly where it was. What arrived is the machinery that can remember it.

The hidden directory is the only new thing
ls -a

The -a option means "also show hidden entries" — on most systems a name beginning with a dot is hidden from ordinary listings. You will see .git sitting alongside your files.

The .git folder

Everything Git records lives inside .git. Every commit, every branch, and later every configuration detail for this particular project.

Two consequences worth holding on to. Delete .git and you delete the entire history while leaving your current files untouched — which is a real and occasionally useful thing to do, and a catastrophic accident otherwise. And copying a project folder copies its history with it, because the history is inside the folder rather than somewhere else.

You will not open .git in this book. What is inside it is genuinely interesting and is the first chapter of the deep dive; none of it is needed to use Git well.

Before and after git init — the files are identical
sandpiper/
the same folder as a minute ago
index.html
untouched — and still untracked
.git/
new — the history lives here
created by git init · never edited by hand

Nothing is being tracked yet

This is the part that surprises people. Ask Git how things stand:

Ask Git what it currently sees
git status

Git reports the branch you are on, says there are no commits yet, and lists index.html as untracked — meaning it can see the file but is not looking after it. Nothing you own is safe yet.

git init starts the history; it does not put anything into it. Putting something in is a separate, deliberate act, and it is the whole of topic 08.

Where init belongs

One project, one repository, at the top of it. Not one per subfolder, and emphatically not in your home folder — running git init there makes a single repository out of your entire computer, including things that must never be committed, and it is a memorable afternoon to undo.

If you are ever unsure whether you are standing in a repository, git status answers immediately: inside one it reports a branch, and outside one it says it is not a Git repository.

Common Confusions
  • "git init saved my files." It saved nothing at all. It built the machinery that can save them. Until you make a commit, Git is watching a project it has recorded nothing about.
  • "I should run it in my home folder so everything is covered." That turns your whole computer into one repository, downloads and private documents included. One project, one repository, and nothing bigger.
  • "Deleting .git deletes my work." It deletes the history and leaves the current files exactly as they are. That is also why .git is the one part of a repository that cannot be recreated from what you can see.
  • "Untracked means something is broken." It means Git can see the file and has not been asked to look after it. Every file starts that way, including the ones you are about to commit.
Why It Matters
  • Knowing that init only builds machinery prevents the most common false sense of safety in a beginner's first week: believing a repository is protecting work that has never been committed.
  • "The history is inside the folder" explains a great deal later — why copying the folder copies the history, and why a stolen laptop takes everything until Chapter 7 puts a copy somewhere else.
  • One project, one repository is the boundary that makes pushing to GitHub, and making a repository public, mean something specific rather than vague.

Knowledge Check

You run git init in a folder containing four files. What has been recorded?

  • Nothing yet, since this command creates the machinery and nothing else at all
  • All four files, as the repository's first commit with an automatic message
  • The file names but not their contents, so the folder structure is preserved
  • Whichever files were modified most recently, as a starting point for the history

What happens if you delete the .git directory?

  • The history disappears and your current files remain exactly as they are
  • Everything in the folder is deleted, including the files you were working on
  • Nothing at all, because Git keeps a second copy of the history elsewhere on disk
  • Git recreates it automatically the next time you run a command in that folder

Why is running git init in your home folder a bad idea?

  • It makes one repository out of your entire computer, private files included
  • Git refuses to create a repository in a home folder and reports an error instead
  • It would overwrite the settings you configured with git config --global
  • It would immediately commit everything in the folder, which could take hours

git status lists index.html as untracked. What does that mean?

  • Git can see the file but has not been asked to record it, so it is not being looked after
  • The file is damaged, and Git cannot read its contents to record them
  • The file has been recorded but has changed since the last commit was made
  • The file is being ignored by a rule, so Git will never record it

You got correct