On Thursday, May 15, 2014 9:36:41 PM UTC+2, Alain wrote:
> Hi,
> Can someone explain me the bare repository functioning ?
> i mean i understood the big picture...that it is used if several people 
> work together in the same company or on the same floor and may change the 
> same file.... where other CVS use locks, Git use Bare repository.
> but what i do not understand is if only 1 person manage the bare 
> repository (setting access right to this repository) on local disk, how can 
> he prevent other people to modify, stage and push changes to it ?
> Moreover, the bare repository is not for only 1 file... :(

A Git repository can and usually does contain many files. It also very 
often has a lot of collaborators that contribute with changes. They do so 
by each keeping their own local non-bare repositories

A bare repository is typically used as a central place for collaboration. 
Usually a group of collaborators (think, a team of developers) shares one 
or more repositories (roughly one repository per product or project). Each 
team member keeps a local clone of the central repository, a local non-bare 
working repository. While a bare repository only contains the "database" 
with the entire history of the repository, a non-bare repository also has a 
"work tree", which is all the latest files checked out and ready to work on.

Physically, they'll look like this. Here's a bare repository (since Git is 
file-based, it's actually just a folder):


In there you'll find packed together copies of all the files that were ever 
part of the repository, and the current state as it is right now. 

Here is the same repository, but this time as non-bare:


The .git folder is basically the same folder as the non-bare foo.git, it 
just has a different name and is placed inside a working repository. You 
need one of these if you actually want to edit the files and commit 
changes. A bare repository, on the other hand, is nice for keeping backups, 
or sharing changes.

> I would like to understand the mechanism. How people can pull/push (having 
> non bare clone) to it, and the person managing the bare repository will 
> manage the pushes/pulls to define what is going or not ?
> i'm lost with it.
Well, it's a bit hard to explain in writing. But imagine this: A team of 
developers share a central bare repository where they all push and pull 
from in order to get the latest code from each other. The usual style of 
management goes like this:

* Everyone can push to the central repository when they wish. There is no 
* If someone else pushes before you do, you have to pull and sync up with 
their changes before you are allowed to push.
* Before you start making changes locally, you'll usually pull and sync up 
just to make sure you have the latest changes from the others
* Once you're done making your local changes, you'll usually pull and sync 
up again before you push. As above, you're not even allowed to push before 
you've done so.

So, that's the quick explanation I had time for now. I tried explaining 
something similar in a talk not so long 
ago: http://youtu.be/U8TkIxJp-w8?t=39m10s - maybe you'll find that useful. 
You could also start reading one of the many great books out there about 
Git. Depends on how you like to learn, I guess :)

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to