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):
foo.git/
config
refs/
objects/
....
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:
foo/
.git/
config
refs/
objects/
....
README.txt
src/
test/
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
manager.
* 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
