Git Init: Create and Initialize Git Repositories Like a Pro

You just deleted a file you worked on for three hours. No undo. No backup. That sinking feeling? That's why Git exists. And it all starts with one command: git init. Most tutorials gloss over it — run the command, done. But get it wrong and you'll be fighting your tool instead of shipping code. Here's what nobody tells you: git init is not just a setup step. It's a decision point that affects how you collaborate, deploy, and recover from disasters. By the end of this, you'll know exactly when to use git init, git init --bare, and how to avoid the footguns that have burned teams I've worked with.

What git init Actually Does Under the Hood

When you run git init, Git creates a .git directory in your project root. This directory is the repository — everything else is just your working tree. Inside .git, you get: objects/ (all your data), refs/ (branches and tags), HEAD (current branch pointer), and a config file. That's it. No magic. No remote. No commits yet. You're just telling Git 'I want you to watch this folder.' The first time you run git add and git commit, Git starts populating the object database. Until then, your repo is empty — a newborn baby with a name but no memories.

// io.thecodeforge — DevOps tutorial

mkdir my-project
cd my-project
git init
ls -la .git
# Output shows the skeleton of a Git repository

Bare Repos: The Server-Side Secret

If you're setting up a central repository that multiple developers push to — like on a server or GitHub Enterprise — you need a bare repository. A bare repo has no working tree. It only contains the .git directory contents. Why? Because if someone pushes to a non-bare repo, Git would try to update the working tree files, which can cause conflicts and data loss. That's why git push to a non-bare repo is rejected by default. The fix: initialize with git init --bare. The --bare flag tells Git to skip the working tree and create only the database. This is how all remote repos on servers should be set up.

// io.thecodeforge — DevOps tutorial

# On the server
mkdir /var/git/my-project.git
cd /var/git/my-project.git
git init --bare

# On a client machine
git clone ssh://user@server/var/git/my-project.git
cd my-project
echo "hello" > README.md
git add README.md
git commit -m "first commit"
git push origin main

Reinitializing an Existing Repo: Safe or Not?

Running git init on an already initialized repo is safe. Git will just reinitialize the .git directory — it won't delete your commits or branches. It's a no-op if the repo already exists. But there's a catch: if you run git init --bare on a non-bare repo, you'll lose your working tree. The command will convert it to bare, but Git will warn you. Don't do it unless you're sure. The safe way to convert a non-bare to bare is to clone it with --bare.

// io.thecodeforge — DevOps tutorial

cd my-project
git init  # safe, even if already a repo
git status  # still shows your working tree

Customizing Your Initialization with Templates

You can customize what goes into .git when you run git init using a template directory. Templates let you pre-populate hooks, config, or even a default .gitignore. This is useful for enforcing company policies — like a commit-msg hook that checks for ticket numbers. Use git init --template=/path/to/template. Git ships with a default template at /usr/share/git-core/templates/. You can override it globally with git config --global init.templateDir /path/to/template.

// io.thecodeforge — DevOps tutorial

mkdir ~/.git-templates
mkdir ~/.git-templates/hooks
cat > ~/.git-templates/hooks/pre-commit << 'EOF'
#!/bin/sh
echo "Running pre-commit hook..."
EOF
chmod +x ~/.git-templates/hooks/pre-commit
git init --template=~/.git-templates my-new-project
ls my-new-project/.git/hooks/

git init vs git clone: When to Use Which

git init creates a new repo from scratch. git clone copies an existing repo. If you're starting a new project, use git init. If you're contributing to an existing project, use git clone. But here's the nuance: you can git init and then add a remote — that's essentially what git clone does internally. git clone is just git init + git remote add + git fetch + git checkout. So if you need fine-grained control (like shallow clone or specific branch), you might git init manually. But 99% of the time, just git clone.

// io.thecodeforge — DevOps tutorial

# Manual equivalent of git clone
git init my-repo
cd my-repo
git remote add origin https://github.com/user/repo.git
git fetch origin
git checkout -b main origin/main

# One-liner
git clone https://github.com/user/repo.git