Create a Git Repository Safely with git init

git init turns a plain directory into a Git repository, and this guide keeps you from doing it in the wrong one. Running it in the wrong directory, or with the wrong default branch, is easy to do and mildly annoying to unpick. The examples use Git 2.43.0, installed here with the git-man documentation package. Allow about five minutes for a normal repository, plus time to decide which files belong in the first commit.

Before you start

• You need: a shell, Git, and a directory containing the project you want to track.
• No elevated privileges required. Use sudo only if the target directory is deliberately owned by another account and you have already checked its path and ownership; running git init as root can leave a repository your normal account cannot update.
• What it will not do: git init only creates repository metadata. It does not create a commit, add files, contact a remote server, or upload anything.

Review files before the first git add, especially configuration files, private keys, tokens, database dumps and build output.

1. Identify the Git version

$ git --version
git version 2.43.0

The exact version can differ on another machine. This local manpage documents Git 2.43.0. Upstream documentation may list options added after that release, so check git init -h on the machine where you will actually run the command.

2. Choose the project directory

$ cd /path/to/my-project
$ pwd
/path/to/my-project

Replace the example path with an existing directory. Do not run the command from a parent directory out of habit: git init applies to the current directory unless you pass a directory argument, and a supplied directory is created if it does not already exist, so check the spelling before relying on that behaviour.

3. Initialise the repository

$ git init --initial-branch=main
Initialized empty Git repository in /path/to/my-project/.git/

The short form is git init -b main. Git creates a hidden .git directory containing the object store, references, configuration and template files. There are no commits yet; an empty initial branch is normal and becomes useful once you make its first commit.

Naming the branch explicitly avoids an easy distraction. Without -b or --initial-branch, Git uses its configured default. On this installed version, an unconfigured repository commonly starts with master and prints a hint that the default may change. Set a project-specific name explicitly when you need main, or configure init.defaultBranch once for future repositories:

$ git config --global init.defaultBranch main

This changes your future initialisations only. It does not rename an existing branch and it does not touch a remote. Treat --global as a deliberate user configuration change, not something to bury in every setup script.

4. Verify what was created

$ git rev-parse --show-toplevel
/path/to/my-project
$ git symbolic-ref --short HEAD
main
$ git status --short
?? README.txt

The first command should name the project directory, and the second should show the branch you just chose. The status output lists untracked files only; it does not mean anything has been committed. If the root is surprising, stop and check pwd and git rev-parse --show-toplevel before adding anything.

5. Add the first commit carefully

$ git status --short
$ git add README.txt src
$ git diff --cached --stat
$ git commit -m "Initial commit"

Do not run git add . until you have checked what it would include. It is convenient, but it can just as easily stage secrets or generated files. If you staged the wrong path, undo the staging without deleting the file:

$ git restore --staged path/to/file

$ mv .git .git-backup
$ git status

Restore the name only after checking the backup. Do not reach for a recursive deletion command until you have confirmed that .git is really the repository you mean to discard.

6. Know your variants

For a server-side repository with no working tree, use a bare repository in a clearly named path:

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

A bare repository is a storage and collaboration endpoint, not a checkout for editing files. The command may need elevated privileges if /srv/git is not writable by your account; check ownership and group policy before sharing it.

To keep repository metadata outside the working tree, use a separate Git directory:

$ git init --separate-git-dir /path/to/project-git -b main /path/to/project
Initialized empty Git repository in /path/to/project-git/

In the working tree, .git becomes a small text file pointing at the actual repository. Keep the two paths together in backups: moving or deleting only one of them makes the working tree look untracked or unusable.

Use --quiet when a script must suppress normal success output while keeping error and warning messages visible. For shared repositories, --shared changes the permissions Git uses under the repository and enables protection against non-fast-forward pushes by default. Treat it as an administrative choice: confirm group membership, umask and backup access before using it. Leave it out of the ordinary single-user command.

Common traps

• Wrong directory. A successful message does not prove you selected the intended project. Verify the root immediately.
• Unexpected branch. Use -b or inspect init.defaultBranch. Do not rename a branch just to paper over uncertainty about the repository location.
• Existing repository. Rerunning git init is normally safe and reports that it reinitialised the repository. It does not erase existing commits, but it is not a substitute for understanding the current layout.
• Permission denied. Check ownership and directory permissions first. Avoid creating root-owned metadata with sudo unless the repository is genuinely meant to be managed by root.
• Missing files after a commit. git init never stages files. Check git status, then add selected paths and inspect git diff --cached.