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 README.md, 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.
Head over to your command line and create a directory called init_locally.
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"
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.
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.
Running
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.
Let us
git add .
and
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 README.md 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 README.md 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 README.md file.
Let us grab the clone URL,
head over to the local command line, and clone the repo.
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.
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 script.py
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 https://github.com/Stevealila/git_init.git
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.
Remote repo shows the last commit with the message, "track JavaScript and Python" 
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
or
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.
Conclusion
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.
