Create a Git Repository Safely with git init

You will turn an existing directory into a Git repository, select its initial branch, and verify that Git is looking at the directory you intended. 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 its first commit.

Before you start

You need a shell, Git, and a directory containing the project you want to track. This guide does not require elevated privileges. 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 that your normal account cannot update.

git init 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.

Checkpoint 1: identify the Git version

1. Run the version check.

$ git --version
git version 2.43.0

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

Checkpoint 2: choose the project directory

1. Change into the directory that should become the project root.

$ 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 by habit: git init applies to the current directory unless you pass a directory argument. A supplied directory is created if it does not exist, so check the spelling before relying on that behaviour.

Checkpoint 3: initialise the repository

1. Create the repository and choose the initial branch explicitly.

$ 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: the branch becomes useful once you make its first commit.

Choosing the branch name avoids an easy distraction. Without -b or --initial-branch, Git uses its configured default. In 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 for future repositories:

$ git config --global init.defaultBranch main

This configuration changes your future initialisations. It does not rename an existing branch and it does not alter a remote. Treat --global as a deliberate user configuration change, not as part of every setup script.

Checkpoint 4: verify what was created

1. Ask Git for the repository root and current branch.

$ 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. The second should show the branch selected in the previous step. The status output lists untracked files only; it does not mean they have been committed. If the root is surprising, stop and inspect pwd and git rev-parse --show-toplevel before adding anything.

Add the first commit carefully

1. Review the files, then stage only the project content you intend to track.

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

Do not use git add . until you have checked what it would include. The broad command is convenient, but it can stage secrets or generated files. If you staged the wrong path, undo the staging without deleting the file:

$ git restore --staged path/to/file

If you have not committed and want to remove the repository metadata entirely, stop first and confirm the target. This is destructive to the local Git history and configuration, although it does not normally delete project files. A safer recovery is to rename .git for inspection, for example:

$ mv .git .git-backup
$ git status

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

Useful 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 require elevated privileges if /srv/git is not writable by your account. After creation, 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 is then 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 appear untracked or unusable.

Use --quiet when a script must suppress normal success output, but keep 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. It is an administrative choice: confirm group membership, umask, and backup access before using it. The ordinary single-user command should omit it.

Common failure points

• Wrong directory: a successful message does not prove that the intended project was selected. Verify the root immediately.
• Unexpected branch: use -b or inspect init.defaultBranch. Do not rename a branch merely to hide 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 do not use it as 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 intentionally 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.