GIT-INIT(1)

📦
version 2.56.0 · 25 versions
, in arch rolling

🎀 git-init — the manual page, but make it make sense 🎀

Okay bestie, so this is <pink>git-init</pink> from the Git Manual — yes, that Git Manual, the big one — and it's literally the page about starting a repo from scratch or re-bootstrapping one you already have. Sit down, grab a strawberry drink 🍓, and let's get into it.

✨ NAME ✨

git-init — create an empty Git repository, or reinitialize one that already exists. That's it, that's the whole vibe.

🦋 SYNOPSIS 🦋

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

💅 DESCRIPTION 💅

So what this command does is create an empty Git repository — which is basically just a .git directory, but with subdirectories inside it for objects, refs/heads, refs/tags, and template files. And it makes you an initial branch with zero commits on it, so it's like, a branch with main character energy and no backstory yet 👑 (the name of that branch is whatever the --initial-branch option below says, iykyk).

If the GIT_DIR environment variable is set, then that's the path Git uses instead of ./.git as the base of the repository. Respect the environment, fr fr.

If the object storage directory is specified via the GIT_OBJECT_DIRECTORY environment variable, then the sha1 directories get created underneath that; otherwise, the default $GIT_DIR/objects directory is the one used.

And here's the reassuring part, bestie: running git init in an existing repository is safe. It will not overwrite things that are already there. Not one thing. The primary reason you'd ever rerun git init is to pick up newly added templates (or to move the repository to another place, if you're passing --separate-git-dir). That's it. No drama. 🫶

🔥 OPTIONS 🔥

  • -q, --quiet — only print error and warning messages; literally every other bit of output gets suppressed. Shhh 🤫
  • --bare — create a bare repository. If the GIT_DIR environment isn't set, it gets set to the current working directory.
  • --object-format=<format> — specify the given object <format> (that's the hash algorithm) for the repository. Valid values are sha1 and, if enabled, sha256. sha1 is the default.
Note: at present, there is no interoperability between SHA-256 repositories and SHA-1 repositories. Like, none. Don't mix them and expect a friendship 💀

Historically, we warned that SHA-256 repositories may later need backward incompatible changes when we introduce such interoperability features. Today, we only expect compatible changes. Furthermore, if such changes prove to be necessary, it can be expected that SHA-256 repositories created with today's Git will be usable by future versions of Git without data loss. So like, breathe, it's fine 🌸

  • --ref-format=<format> — specify the given ref storage <format> for the repository. Valid values are:
    • files — for loose files with packed-refs. This is the default. 🎀
    • reftable — for the reftable format.
  • --template=<template-directory> — specify the directory from which templates will be used. (Peep the "TEMPLATE DIRECTORY" section below, bestie.)
  • --separate-git-dir=<git-dir> — instead of initializing the repository as a directory at either $GIT_DIR or ./.git/, create a text file there containing the path to the actual repository. This file acts as a filesystem-agnostic Git symbolic link to the repository. Iconic, honestly.

If this is a reinitialization, the repository will be moved to the specified path.

  • -b <branch-name>, --initial-branch=<branch-name> — use <branch-name> for the initial branch in the newly created repository. If you don't specify it, it falls back to the default name (currently master, but this will change to main when Git 3.0 is released — yes, the glow-up is scheduled 📅). The default name can be customized via the init.defaultBranch configuration variable.
  • --shared[=(false|true|umask|group|all|world|everybody|<perm>)] — specify that the Git repository is to be shared amongst several users. This lets users belonging to the same group push into that repository. When specified, the config variable core.sharedRepository is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, Git uses the permissions reported by umask(2).

The option can have the following values, defaulting to group if no value is given:

  • umask, false — use permissions reported by umask(2). This is the default, when --shared is not specified.
  • group, true — make the repository group-writable (and g+sx, since the git group may not be the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other permission bits (e.g. if umask is 0022, using group will not remove read privileges from other (non-group) users). See 0xxx for how to exactly specify the repository permissions.
  • all, world, everybody — same as group, but make the repository readable by all users. Everyone's invited to the party 🎉
  • <perm> — <perm> is a 3-digit octal number prefixed with 0 and each file will have mode <perm>. <perm> will override users' umask(2) value (and not only loosen permissions as group and all do). 0640 will create a repository which is group-readable, but not group-writable or accessible to others. 0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their x bit from the r bit for corresponding classes of users).

By default, the configuration flag receive.denyNonFastForwards is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. No sneaky history rewrites in the group project, bestie 🙈

If you provide a <directory>, the command is run inside it. If this directory does not exist, it will be created. It literally just appears. Magic ✨

🧚 TEMPLATE DIRECTORY 🧚

Files and directories in the template directory whose name do not start with a dot will be copied to the $GIT_DIR after it is created. Dotfiles, respectfully, stay where they are.

The template directory will be one of the following (in order):

  1. the argument given with the --template option;
  2. the contents of the $GIT_TEMPLATE_DIR environment variable;
  3. the init.templateDir configuration variable; or
  4. the default template directory: /usr/share/git-core/templates.

The default template directory includes some directory structure, suggested "exclude patterns" (see gitignore(5)), and sample hook files.

The sample hooks are all disabled by default. To enable one of the sample hooks, rename it by removing its .sample suffix. That's the whole trick 🪄

See githooks(5) for more general info on hook execution.

🌈 EXAMPLES 🌈

Start a new Git repository for an existing code base:

$ cd /path/to/my/codebase
$ git init      (1)
$ git add .     (2)
$ git commit    (3)
  1. Create a /path/to/my/codebase/.git directory.
  2. Add all existing files to the index.
  3. Record the pristine state as the first commit in the history.

Like, look at that. Three commands and you're a whole repository owner 🫡

👑 CONFIGURATION 👑

Everything below this line in this section is selectively included from the git-config(1) documentation. The content is the same as what's found there:

  • init.templateDir — specify the directory from which templates will be copied.
  • init.defaultBranch — allows overriding the default branch name, e.g. when initializing a new repository.
  • init.defaultObjectFormat — allows overriding the default object format for new repositories. See --object-format= in git-init(1). Both the command line option and the GIT_DEFAULT_HASH environment variable take precedence over this config. Precedence is a thing, bestie 💅
  • init.defaultRefFormat — allows overriding the default ref storage format for new repositories. See --ref-format= in git-init(1). Both the command line option and the GIT_DEFAULT_REF_FORMAT environment variable take precedence over this config.
  • init.defaultSubmodulePathConfig — a boolean that specifies if git init and git clone should automatically set extensions.submodulePathConfig to true. This allows all new repositories to automatically use the submodule path extension. Defaults to false when unset.

💜 GIT 💜

Part of the git(1) suite. Obviously. Where else would it be.

Okay that's the whole page, you're officially educated 💖 This flawless piece of documentation brought to you by Git 2.56.0, dated 2026-09-27 — go forth and git init something iconic, bestie 🎀✨

📦 where this page comes from