git init

Bootstrap a .git directory in any folder and turn it into a Git repo.

🎯 What & why

Turn an ordinary directory into a Git repository. Creates a .git/ subdirectory containing the object database, the HEAD pointer, an empty index, and a default branch ref. Nothing else changes — your files are untouched.

🧠 Mental model

After git init, you have a tracker watching the directory but tracking nothing yet. The object database is empty. HEAD is a symbolic ref pointing at refs/heads/master (or main), but that ref doesn't exist on disk until you make your first commit. Knowing that explains why git log errors right after init: there's no commit to walk.

🛠️ Synopsis

git init [-q | --quiet] [--bare] [--template=<dir>]
         [--separate-git-dir=<git-dir>] [--object-format=<format>]
         [-b <branch> | --initial-branch=<branch>]
         [--shared[=<perm>]] [<directory>]

🎚️ Switches & options

Flag	What it does
`-b <name>`	Set the initial branch name (e.g. `-b main`). Beats setting `init.defaultBranch` in config when you only want it for this repo.
`--bare`	Make a bare repo — no working tree. Used for serving repos over the network.
`--template=<dir>`	Copy hooks/info from a template directory into the new `.git/`.
`--separate-git-dir=<dir>`	Put the `.git` contents somewhere else; leave a `.git` file in the working tree pointing to it. Useful for SSDs/HDDs split, or for putting `.git` outside the workspace.
`--shared=group`	Set group-writable permissions on the new repo. For shared NFS/multi-user setups.
`--object-format=sha256`	Use SHA-256 instead of SHA-1. Almost no remote ecosystem speaks it yet — set it knowing what you'll lose.
`--quiet`	Suppress the friendly status output.

💡 Use cases

Starting a brand-new project locally before pushing it anywhere.
Wrapping an existing un-versioned project in Git so you stop emailing yourself zip files.
Creating a --bare repo on a server that other clones will push to.
Adopting a directory full of binaries — let git status tell you what you're walking into before staging anything.

🧪 Examples

Init in the current directory.

$ git init
Initialized empty Git repository in /home/me/proj/.git/

Init with main as the initial branch (no global config required).

$ git init -b main
Initialized empty Git repository in /home/me/proj/.git/

Bare repo, suitable for git clone user@host:repos/proj.git.

$ git init --bare /srv/git/proj.git
Initialized empty Git repository in /srv/git/proj.git/

Reinitialize an existing repo (refreshes hooks template, keeps history).

$ git init -b main
Reinitialized existing Git repository in /home/me/proj/.git/

🎓 Recommendations

Always set the initial branch name explicitly with -b. Don't rely on the global default — your future self forking this repo somewhere new will thank you.
Set init.defaultBranch once globally (git config --global init.defaultBranch main) and then forget about it.
For a shared server, prefer init --bare. Don't try to push into a repo with a working tree — Git will reject it for good reasons.

🪤 Common pitfalls

Running git init inside a directory that's already a Git repo just reinitializes it. Harmless, but surprising — confirm with git status afterwards.
If you init inside a parent repo, the new .git/ will be ignored by the parent. You've created a sub-repo that's not a submodule. Almost always wrong.
Using --object-format=sha256 produces a repo most platforms (GitHub, etc.) still can't host. Wait for the ecosystem.

🔗 Related modules

📝 Quiz

Hit each option, then Check answers. Score is recorded; Next is always open.