What s the -practical- difference between a Bare and non-Bare repository

Question

I ve been reading about the bare and non-bare   default repositores in Git  I haven t been able to understand quite well  theoretically  about the differences between them  and why I should  push  to a bare repository  Here s the deal   Currently  I m the only one working on a project on 3 different computers  but there will be more people involved in it later  so I m using Git for the version control  I clone the bare repo on all computers  and when I finish my modifications on one of them  I commit and push the changes to the bare repo  From what I ve read  the bare repository does NOT have a  working tree   so if I clone the bare repo  I won t have a  working tree    I m guessing that the working tree stores the commit information  branches  etc  from the project  That wouldn t appear in the bare repo  So it seems better for me to  push  the commits to the repo with the working tree   Then  why should I use the bare repository and why not  What s the practical difference  That would not be beneficial to more people working on a project  I suppose   What are your methods for this kind of work  Suggestions

User · Answer

This is not a new answer  but it helped me to understand the different aspects of the answers above  and it is too much for a comment     Using Git Bash just try   me pc MINGW64  c Test   ls -al total 16 drwxr-xr-x 1 myid 1049089 0 Apr  1 11 35    drwxr-xr-x 1 myid 1049089 0 Apr  1 11 11      me pc MINGW64  c Test   git init Initialized empty Git repository in C  Test  git   me pc MINGW64  c Test  master    ls -al total 20 drwxr-xr-x 1 myid 1049089 0 Apr  1 11 35    drwxr-xr-x 1 myid 1049089 0 Apr  1 11 11     drwxr-xr-x 1 myid 1049089 0 Apr  1 11 35  git   me pc MINGW64  c Test  master    cd  git  me pc MINGW64  c Test  git  GIT DIR     ls -al total 15 drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35    drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35     -rw-r--r-- 1 myid 1049089 130 Apr  1 11 35 config -rw-r--r-- 1 myid 1049089  73 Apr  1 11 35 description -rw-r--r-- 1 myid 1049089  23 Apr  1 11 35 HEAD drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35 hooks  drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35 info  drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35 objects  drwxr-xr-x 1 myid 1049089   0 Apr  1 11 35 refs    Same with git --bare   me pc MINGW64  c Test   ls -al total 16 drwxr-xr-x 1 myid 1049089 0 Apr  1 11 36    drwxr-xr-x 1 myid 1049089 0 Apr  1 11 11      me pc MINGW64  c Test   git init --bare Initialized empty Git repository in C  Test   me pc MINGW64  c Test  BARE master    ls -al total 23 drwxr-xr-x 1 myid 1049089   0 Apr  1 11 36    drwxr-xr-x 1 myid 1049089   0 Apr  1 11 11     -rw-r--r-- 1 myid 1049089 104 Apr  1 11 36 config -rw-r--r-- 1 myid 1049089  73 Apr  1 11 36 description -rw-r--r-- 1 myid 1049089  23 Apr  1 11 36 HEAD drwxr-xr-x 1 myid 1049089   0 Apr  1 11 36 hooks  drwxr-xr-x 1 myid 1049089   0 Apr  1 11 36 info  drwxr-xr-x 1 myid 1049089   0 Apr  1 11 36 objects

User · Answer

I m certainly not a Git  expert   I have used TortoiseGit for a while  and wondered what it was talking about when it asked me if I wanted to make a  bare  repo whenever I created one   I was reading this tutorial  https   www atlassian com git tutorials setting-up-a-repository git-init and it addresses the issue  but I still was not quite understanding the concept   This one helped a lot  http   bitflop com tutorials git-bare-vs-non-bare-repositories html   Now  the first one makes sense too   According to these sources  in a nutshell a  bare  repo is used on a server where you want to setup a distribution point   It s not intented for use on your local machine   You generally push commits from your local machine to a bare repo on a remote server  and you and or others pull from that bare repo to your local machine   So your GitHub  Assembla  etc  remote storage   distribution repo is an example where a  bare  repo is created   You would make one yourself if you were setting up your own analogous  sharing center

User · Answer

Another difference between a bare and non-bare repository is that a bare repository does not have a default remote origin repository     Projects  git clone --bare test bare Initialized empty Git repository in  home derek Projects bare    Projects  cd bare   Projects bare  git branch -a   master   Projects bare  cd      Projects  git clone test non-bare Initialized empty Git repository in  home derek Projects non-bare  git    Projects  cd non-bare   Projects non-bare  git branch -a   master   remotes origin HEAD - gt  origin master   remotes origin master   From the manual page for git clone --bare      Also the branch heads at the remote   are copied directly to corresponding   local branch heads  without mapping   them to refs remotes origin   When   this option is used  neither   remote-tracking branches nor the   related configuration variables are   created    Presumably  when it creates a bare repository  Git assumes that the bare repository will serve as the origin repository for several remote users  so it does not create the default remote origin   What this means is that basic git pull and git push operations won t work since Git assumes that without a workspace  you don t intend to commit any changes to the bare repository     Projects bare  git push fatal  No destination configured to push to    Projects bare  git pull fatal   usr lib git-core git-pull cannot be used without a working tree    Projects bare

User · Answer

A bare repository has benefits in    reduced disk usage  less problems related to remote push  since no working tree is there to get out of synch or have conflicting changes

User · Answer

Non bare repository allows you to  into your working tree  capture changes by creating new commits    Bare repositories are only changed by transporting changes from other repositories

User · Answer

A non-bare repository simply has a checked-out working tree  The working tree does not store any information about the state of the repository  branches  tags  etc    rather  the working tree is just a representation of the actual files in the repo  which allows you to work on  edit  etc   the files

User · Answer

A bare repository is nothing but the  git folder itself i e  the contents of a bare repository is same as the contents of  git folder inside your local working repository    Use bare repository on a remote server to allow multiple contributors to push their work  Non-bare - The one which has working tree makes sense on the local machine of each contributor of your project

User · Answer

The distinction between a bare and non-bare Git repository is artificial and misleading since a workspace is not part of the repository and a repository doesn t require a workspace   Strictly speaking  a Git repository includes those objects that describe the state of the repository   These objects may exist in any directory  but typically exist in the  git directory in the top-level directory of the workspace   The workspace is a directory tree that represents a particular commit in the repository  but it may exist in any directory or not at all   Environment variable  GIT DIR links a workspace to the repository from which it originates   Git commands git clone and git init both have options --bare that create repositories without an initial workspace   It s unfortunate that Git conflates the two separate  but related concepts of workspace and repository and then uses the confusing term bare to separate the two ideas

User · Answer

git help repository-layout  A Git repository comes in two different flavours   a  git directory at the root of the working tree  a  git directory that is a bare repository  i e  without its own working tree   that is typically used for exchanging histories with others by pushing into it and fetching from it

User · Answer

A default non-bare Git repo contains two pieces of state    A snapshot of all of the files in the repository  this is what  working tree  means in Git jargon  A history of all changes made to all the files that have ever been in the repository  there doesn t seem to be a concise piece of Git jargon that encompasses all of this    The snapshot is what you probably think of as your project  your code files  build files  helper scripts  and anything else you version with Git   The history is the state that allows you to check out a different commit and get a complete snapshot of what the files in your repository looked like when that commit was added  It consists of a bunch of data structures that are internal to Git that you ve probably never interacted with directly  Importantly  the history doesn t just store metadata  e g   User U added this many lines to File F at Time T as part of Commit C    it also stores data  e g   User U added these exact lines to File F     The key idea of a bare repository is that you don t actually need to have the snapshot  Git keeps the snapshot around because it s convenient for humans and other non-Git processes that want to interact with your code  but the snapshot is just duplicating state that s already in the history   A bare repository is a Git repository that does not have a snapshot  It just stores the history   Why would you want this  Well  if you re only going to interact with your files using Git  that is  you re not going to edit your files directly or use them to build an executable   you can save space by not keeping around the snapshot  In particular  if you re maintaining a centralized version of your repo on a server somewhere  i e  you re basically hosting your own GitHub   that server should probably have a bare repo  you would still use a non-bare repo on your local machine though  since you ll presumably want to edit your snapshot    If you want a more in-depth explanation of bare repos and another example use case  I wrote up a blog post here  https   stegosaurusdormant com bare-git-repo

User · Answer

5 years too late  I know  but no-one actually answered the question      Then  why should I use the bare repository and why not  What s the   practical difference  That would not be beneficial to more people   working on a project  I suppose       What are your methods for this kind of work  Suggestions    To quote directly from the Loeliger MCullough book  978-1-449-31638-9  p196 7       A bare repository might seem to be of little use  but its role is   crucial  to serve as an authoritative focal point for collaborative   development  Other developers clone and fetch from the bare   repository and push updates to it    if you set up a repository into   which developers push changes  it should be bare  In effect  this is   a special case of the more general best practice that a published   repository should be bare

[git] What's the -practical- difference between a Bare and non-Bare repository?

Examples related to git

Examples related to repository

Examples related to git-bare