ok i have to try this thank you
On Fri, Jun 28, 2013 at 11:38 AM, Dale R. Worley <wor...@alum.mit.edu>wrote:
> 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 a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/groups/opt_out.
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 https://groups.google.com/groups/opt_out.