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 repository. 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 used. 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. Dale -- 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/groups/opt_out.
