Decoding git init for you and when to use it?

Git init is a command to instantiate a repo.

git init

Sometimes you need to customize your workflow with various git init flags, such as bare, quiet, separate, shared, and template.


It would help to view a practical usage of the git command on a local or remote repo. Before that, you should understand the git workflow to identify the best environment to apply it.


The role of git init in a git workflow

Git, as a distributed version control system, tracks file changes. It keeps a snapshot of your files in the staging area and stores the final version of the project in a database. The entire process occurs in three stages: add, commit and save.

Adding changes tells git to start tracking files, while a commit takes files from the staging area and saves them in the database. You need git init to notify git to create room for tracking the files.

Once you have initialized git, you are free to control the workflow through branching, merging, pulling, pushing, and cloning the repo. As outlined in the following section, you can extend your git init knowledge through a typical git workflow practice.


Lab setup to practice git init

Let us create a remote repo without a, then clone it to learn git init with local and remote repos. The remote repo will play a critical role in examining the usage of git init remotely. Likewise, we will use the local repo to instantiate the git repo locally.

I am creating a remote repo called git_init on Github.


repo to practice git init

Head over to your command line and create a directory called init_locally.

Decoding git init for you and when to use it?

Let us get started with the local repo.


Example-1: Using git init with local repo

It would help to differentiate the steps of saving a file in git remotely vs locally.

In a remote repo, it usually takes two steps to save files. All you do is create a file and save it. And voila, your files are in tracking mode!

On a local directory, you create a directory and files. Next, you save the files before adding and committing the changes. Here, the commit is a second form of saving in the workflow.

After saving the files locally, git does not track them automatically. Let us see that in action.

cd into init_locally directory.

If you type

git status

you get a fatal error, "fatal: not a git repository (or any of the parent directories):. git"

Decoding git init for you and when to use it?

What if we add and save files in the directory? Let us see what happens.

touch file1.txt file2.txt

Save the files and run the command

git status

You realize the repo still shows the fatal error.

Decoding git init for you and when to use it?

Checking tracked files produces a similar result.

git ls-files

Now is the time to start tracking the files.

Run the command

git init

What do you notice?

Git informs us, "Initialized empty Git repository in <directory>.git"

Recheck the status.

git status

Git has baptized the directory ending with master label meaning our files will reside in git's ecosystem under a branch called master.

Decoding git init for you and when to use it?


ls -la

shows all the files, including the hidden .git folder.

After initializing a repo, git creates a .git folder to track the files and configure the tracking pattern. By default, the folder gets hidden to prevent tampering with it.

Decoding git init for you and when to use it?

Let us

git add .


git commit -m "commit 1"

before proceeding with a remote repo.


Example-2: Using git init with remote repo

Let us return to the Github repo we created earlier.

There are two ways to track files from a remote repo. First, you can use GUI tools to create and save files in a remote repo. That process undergoes massive encapsulation that you may forget that the add and commit stages exist.

Secondly, you can create an empty repo and control it from your local machine's command line or terminal. Connecting the two environments usually happens through SSH or by cloning the repo.

You probably wondered why we did not create a file when creating the Github repo. The reason is that we wanted to start file tracking from scratch.

Github initializes a repo on your behalf on creating a file on the platform. It creates some files when building a remote initializes the repo, adds and commits the primary files for you.

Apart from automatic commit, you can push and pull changes from the repo without initializing a repo or doing a git set upstream when you clone a repo with a file.

Let us grab the clone URL,

Decoding git init for you and when to use it?

head over to the local command line, and clone the repo.

Decoding git init for you and when to use it?

Git tells us that the repo is empty, and using it requires tracking the files from scratch.

Running the command

git log

reveals that our remote URL lacks an uninitialized repo.

Decoding git init for you and when to use it?

In other words, git says our repo lacks a branch because we have not initialized a remote repo. If you don't expect the repo to be empty, contact the admin who presented you with the link.

Let us create some files before tracking them. cd into the new folder, git_init, by running these commands:

git init

Create files.

touch main.js

Add and commit the files to the local git repo.

git add *
git commit -m "track JavaScript and Python"

Finally, let us push the changes to a remote repo using the steps outlined on Github.

git remote add origin
git branch -M main
git push -u origin main

If you get the message, "error: remote origin already exists," follow the steps outlined in the following screenshot to reset your remote repo and push code to it.
Decoding git init for you and when to use it?

Remote repo shows the last commit with the message, "track JavaScript and Python" Decoding git init for you and when to use it?

The above examples prove how git init enables us to manage a repo from the root directory. If you want to customize your repo further, you can introduce specific configuration options when using git init. Here are a few examples.


Top 5 git init options you should know!

The flags you can use to instantiate a repo are bare, quiet, separate, shared, and template.

1. bare

The --bare flag creates a central remote repo, letting you handle push and pull requests without adding or committing changes into the repo.

The command

git init --bare

tells git to omit the working directory when initializing an empty repo and keep the tracked files in the <project.git> folder.


2. quiet

With git init quiet, you only show the most significant messages, warnings, and errors when managing a repo. Its command is

git init --quiet


git init -q


3. separate

The separate flag creates a text file with the path to the exact directory. You specify the directory by running the command

git init --separate-git-dir <target directory>


4. shared

shared flag enables you to specify user roles when pushing or pulling changes to the repo.

git --shared[=<permissions>]

Typical permissions are FALSE, TRUE, EVERYBODY, GROUP, or ALL.


5. template

Lastly, the git init template is best for creating a reference directory. You initialize a directory and copy files, creating a repo with a.git subdirectory.

Its command is:

git init --template=<template_directory>

The above five are the standard git init flags. You can find more flags on official git docs.



Git init informs git to begin tracking files. It can be crucial in a local or remote environment to track directories and files, as you saw in this tutorial. You can also customize it with various flags to ease control while managing a repo. Go ahead and apply it.


Didn't find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

Leave a Comment