As I understand it, the bare repository is created as a buffer between the main copy on the server and the development branches.

But I don’t fully understand, reading the article “successful branching model “, why this type of repository is needed if everything should work and so on.

Answer 1, authority 100%

bare repository is not some special type of repository. this is actually the repository .

the command git init --bare creates the repository in the current directory:

$ git init --bare
$ ls -F
branches / config * description HEAD hooks / info / objects / refs /

and with the git init command (without the --bare option) the repository is created in the .git directory:

$ git init
$ ls -F .git
branches / config * description HEAD hooks / info / objects / refs /

which allows the current directory to be used as a working dir (working dir ) with checked out files / directories from the repository, the versions of which are tracked by this repository (in general, the working directory can be located in a completely different place and specified to the git program using the -C or --work-tree options, or a combination of both (these options are not equivalent), or the GIT_WORK_TREE environment variable, or the core.worktree config variable).

“turning” bare into non-bare (and vice versa) is very easy: just change the value (true or false ) of the bare variable in the [core] section of the config file. manually or with the git config core.bare value command. that is, in fact, this is some kind of sign, which in practice means that “there is a working directory with monitored files nearby.”

why is this feature needed?

so that when trying to “push” into the current branch (the one pointed to by the contents of the HEAD file) a “repository with a working directory” (non-bare repository) the user was getting error and detailed explanation:

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 yo
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 behavior, set
remote: error: ‘receive.denyCurrentBranch’ configuration variable to ‘refuse’

my free translation:

Refused to update the refs / heads / master branch from which the files were checked out into the working directory.

By default, updating the current branch in a non-bare repository is prohibited, because this will result in a mismatch between what you push and the index and contents of the working directory, and will require git reset --hard to bring the working directory into line with the current branch, i.e. the one specified in the HEAD file.

you can set the value of the receive.denyCurrentBranch config variable of the remote repository to ignore or warn to allow push to its current branch; however, this is not recommended unless you have configured (automatic) updating of the working directory in some other way.

You can disable the issuance of this message without changing the default behavior by setting the variable Receive.denyCurrentBranch Value Refuse .

Answer 2, Authority 18%

If briefly, the BARE is the repository on the server. But Git (unlike SVN) decentralized, and servers can be as much as you like. Even on one machine.