Generally, for simple projects with multiple developers, the pattern
is to have one central "bare" repository that is the "official" copy
of all the commits.

Each developer then has their own repository with an attached working
directory.  Each repository is created as a "clone" of the central
repository, which means that it contains a more-or-less complete set
of commits as well, and contains a pointer back to the contral

If the files need to be used on the server, then create another clone
on the server whose working directory is the place where the files are

Each developer works in their own working directory.  When they want
to check something in, they commit their changes to their repo.  This
creates a new commit in their repo.  They then "push" changes to the
central repo, which causes the new commit(s) to be copied from their
repo to the central repo.

When a developer wants to obtain updates from the central repo, they
do a "pull", which causes any new commits from the central repo to be
copied to their repo.  When the developer changes his checked-out
commit to be the newest downloaded commit, then his working directory
is updated accordingly.  This is the point at which conflicts will
show up, and merging may be needed to fix them.


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 
For more options, visit

Reply via email to