What is the difference between "git init" and "git init --Bare"?

Question

The question is very simple indeed:

What is the difference between these two commands, git init and git init --bare?

What is this option for --bare?

Answer 1

With the command git init --bare you are creating a repository that is pushable. Generally the repositories bare are created on the server and are considered repositories for storage, in contrast to the repositories that go on the developers' machines that would be the development repositories, created with the command git init (without the --bare).

Although GIT is a distributed versioning control system, it is very common to have a central repository that facilitates the exchange of information between developers, avoiding the need for developers' computers to communicate directly with each other.

An illustration of the paragraph above:

What’s more, repositories bare do not have Working directory, making it impossible to edit and commit files in that repository.

Below is an image of the flow of the developers' GIT repositories (no-bare):

Source: Atlassian - Setting up a Repository

Answer 2

What is:

By initializing a repository as Bare you won’t be allowed to edit files (git add) and commit changes (git commit), since it doesn’t have a Working Tree. You should update a Bare repository using git push.

When it is used:

You initialize a repository as Bare when you want it to be the central respository.

Answer 3

Another difference between --Bare and Working Tree repositories is that in the first case no commits are stored, but only commits that belong to a branch’s track are stored. See below...

I created the first repository (name: git-Bare) with git init --bare. That is, it is the server. It is the one on the left side, where there are no remote branches because this is the remote repository itself.

I created the second repository (name: git-Working-Tree) with git clone receiving from the first. It is the one on the right. It has local branches linked to the remote branches.

(The texts 'first', 'Second', 'third', 'Fourth', 'alpha', 'beta' and 'delta' are the comments of the commits. The names 'master' and 'Greek' are branch names.)

Now I’m going to delete the branch called 'Greek' both on git-Bare (commando: git push --delete origin greek) as locally in git-Working-Tree (commando: git branch -D greek). See how the tree looks:

The repository git-Bare deletes both the branch and its comits. That’s why the name 'Bare' has the sense of pure. It only stores the comits that can be referenced. In the picture we see that his tree was reduced for this reason.

On the other hand, the repository git-Working-Tree, which is equivalent to a local repository that we commonly use, does not delete commits, which can now only be referenced directly by your hash with a command of the type git checkout 7fa897b7. That’s why your tree doesn’t have its modified structure.

IN SUMMARY: commits are never discarded in repositories of the type Working-Tree, but are deleted in repositories like Bare.

In practical terms, you can only recover a deleted branch on the server if it exists in a local repository. This is because he and his commits have been completely removed from the server.

But it’s very strange that the size of the repository Bare does not decrease disk size after deleting a remote branch. That is, the files are still there somehow. To dry the repository by deleting what is no longer referenced or what can never be referenced (the latter case) use the command git gc --prune