Git workflow without a server
What you need to do first, is to think through what kind of workflow you have already and configure git to work with that. Once you have something up and running, you can fine tune it. There is no need to setup a separate computer as a server. If you are accustomed to have a central repository all you need to do is to create a bare repository that everyone pushes to. Why not on the local network?
Central repo:
mkdir foo.git
cd foo.git
git init --bare
Your repo:
mkdir foo
cd foo
git init
// add files
git add .
git commit -m "Initial commit"
git remote add origin //path/to/central/repo/foo.git
git push origin master
Other repos:
git clone //path/to/central/repo/foo.git
Now anyone can push and pull directly from master branch. This should be enough to get you started.
Depends on what you mean by "server". Git will work happily without a central server, although many teams find it convenient to have a central repository.
If by "server", you mean "install server software", git will also work (central repository or not) without any special software, through ssh or on the file system.
See this document for possible workflows
Workflow with common repository
The workflow that many use is that all developers "push" (send) their changes to a common repository, and get all the changes from that repository. Something like this:
- Developer A pushes to central
- Developer B pushes to central
- Developer C pulls (getting changes from A and B)
- Developer A pulls (getting changes from B)
- ...
In this case the central repository can be on one of the Developers computers, on github, or any other place
Workflow with Email
You can also use git without any server, just using email. In this case the flow would be like this:
- Developer A sends changes as an email to the team
- Other developers apply the changes from the emails
This can even be done in a semi-automated way
Workflow without a central server
You can setup git to use more than one "remote" repository. The caveat is that you should never push to a repository that is checked out (that is, a Developer copy on which someone is working). So in this case the flow would be like this:
- Developer A makes changes
- Developer B makes changes
- Developer C pulls changes from A
- Developer C pulls changes from B
- Developer B pulls changes from A
- ...
- No one must ever push
IMHO this type of workflow will quickly lead to confusion and breakdown.