Read Anthropic’s case study about Graphite Reviewer

How to initialize a new Git repository with the Git init command

Greg Foster
Greg Foster
Graphite software engineer


Note

This guide explains this concept in vanilla Git. For Graphite documentation, see our CLI docs.


The git init command is designed to set up a new Git repository, laying the groundwork for all future version control operations. This guide explores the git init command, including how it works under the hood, and details the underlying structure of a git repository.

The git init command is used to initialize a new Git repository. It prepares a new directory to be used for version control by Git, creating the necessary data structures (referred to as a .git directory) that store the repository's configuration and history.

  1. Navigate to Your Project Directory: Before running git init, navigate to the root directory of your project using the command line or terminal.
Terminal
cd path/to/your-project
  1. Initialize the Repository:
Terminal
git init

Running this command creates a new subdirectory named .git in your project directory. This .git directory contains all the necessary repository files — a skeleton repository. No files are tracked yet.

  1. HEAD:

    • The HEAD file is a reference to the current branch that's checked out. By default, it points to the master or main branch, but it won't actually refer to a valid branch until you make your first commit. It can also point to a commit if you're in a 'detached HEAD' state.
  2. config:

    • This file contains repository-specific configuration settings. These settings can include user information, remote repository URLs, and branch configurations. The settings here override the global Git configuration settings for this specific repository.
  3. objects/:

    • The objects directory stores all the data for your commits, including files and the structure of the commit tree. This data is stored in a compressed format, making Git very efficient. The objects are identified by a SHA-1 hash of their content.
  4. refs/:

    • The refs directory contains references to commit objects in the repository, organized into subdirectories such as heads/ for branch heads and tags/ for tag objects. These references are updated as you commit and branch within your repository.
  5. hooks/:

    • This directory contains client-side or server-side scripts that are invoked at different phases of the Git workflow, such as before a commit is finalized (pre-commit) or before pushing to a remote repository (pre-push). By default, Git populates this directory with example scripts. These scripts are not active until renamed (removing the .sample extension).
  6. info/:

    • Inside, you'll find the exclude file, which works like a .gitignore file but is specific to this repository. The patterns listed in the exclude file will be ignored by Git, similar to how .gitignore works, but without the need to commit this file into the repository.
  7. description:

    • This file is only used by the GitWeb program, which is a Git web interface. By default, it contains a placeholder text ("Unnamed repository; edit this file 'description' to name the repository."), which can be changed to provide a meaningful description of your repository for viewers on GitWeb.
  8. index:

    • The index file (not present immediately after git init but created upon first adding files to the staging area) acts as the staging area ("index") for Git. It tracks which files will be included in the next commit.

The .git directory and its contents are vital for Git's version control capabilities. Each file and directory plays a specific role in tracking changes, managing configurations, and facilitating hooks for custom Git workflows. Directly modifying files in the .git directory directly can lead to repository corruption, so such actions should only be taken by users who fully understand the consequences.

Initial branch configuration: git init also sets up an initial branch (traditionally main). However, this branch doesn't have any commits until you make your first commit.

After initializing a repository, you may want to configure user information specific to that repository:

Terminal
git config user.name "Your Name"
git config user.email "youremail@example.com"

This step is crucial for collaborative projects, as each commit in Git is associated with a user name and email address.

While git init is used to create a new repository, git clone is used to copy an existing repository. If you're starting a new project from scratch use git init. If you're contributing to an existing project or want to create a local copy of a project, you'll use git clone followed by the repository's URL.

  • One project per repository: It's a best practice to keep each Git repository limited to a single project or logical grouping of files to maintain clarity and organization.

  • Immediate .gitignore creation: After initializing your repository, create a .gitignore file to specify intentionally untracked files that Git should ignore. Common examples include compiled code, system files, and editor configuration.

For further details and advanced options, the git init documentation is a comprehensive resource:

Terminal
git init --help

or you can visit the official Git documentation online.

Graphite
Git stacked on GitHub

Stacked pull requests are easier to read, easier to write, and easier to manage.
Teams that stack ship better software, faster.

Or install our CLI.
Product Screenshot 1
Product Screenshot 2