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

Non-Bare Git Repo

This variant creates a repository with a working directory so you can actually work (git clone). After creating it you will see that the directory contains a .git folder where the history and all the git plumbing goes. You work at the level where the .git folder is.

Bare Git Repo

The other variant creates a repository without a working directory (git clone --bare). You don't get a directory where you can work. Everything in the directory is now what was contained in the .git folder in the above case.

Why You Would Use One vs. the Other

The need for git repos without a working directory is the fact that you can push branches to it and it doesn't manage what someone is working on. You still can push to a repository that's not bare, but you will get rejected as you can potentially move a branch that someone is working on in that working directory.

So in a project with no working folder, you can only see the objects as git stores them. They are compressed and serialized and stored under the SHA1 (a hash) of their contents. In order to get an object in a bare repository, you need to git show and then specify the sha1 of the object you want to see. You won't see a structure like what your project looks like.

Bare repositories are usually central repositories where everyone moves their work to. There is no need to manipulate the actual work. It's a way to synchronize efforts between multiple people. You will not be able to directly see your project files.

You may not have the need for any bare repositories if you are the only one working on the project or you don't want/need a "logically central" repository. One would prefer git pull from the other repositories in that case. This avoids the objections that git has when pushing to non-bare repositories.

Hope this helps

Short answer

A bare repository is a git repository without a working copy, therefore the content of .git is top-level for that directory.

Use a non-bare repository to work locally and a bare repository as a central server/hub to share your changes with other people. For example, when you create a repository on github.com, it is created as a bare repository.

So, in your computer:

git init
touch README
git add README
git commit -m "initial commit"

on the server:

cd /srv/git/project
git init --bare

Then on the client, you push:

git push username@server:/srv/git/project master

You can then save yourself the typing by adding it as a remote.

The repository on the server side is going to get commits via pull and push, and not by you editing files and then commiting them in the server machine, therefore it is a bare repository.

Details

You can push to a repository that is not a bare repository, and git will find out that there is a .git repository there, but as most "hub" repositories do not need a working copy, it is normal to use a bare repository for it and recommended as there is no point in having a working copy in this kind of repositories.

However, if you push to a non bare repository, you are making the working copy inconsistent, and git will warn you:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

You can skip this warning. But the recommended setup is: use a non-bare repository to work locally and a bare repository as a hub or central server to push and pull from.

If you want to share work directly with other developer's working copy, you can pull from each other repositories instead of pushing.