Git Workflow: Without a server

问题:

git is supposed to be a decentralized system, but all the tutorials and best practice workflows I have found on google suggest using a server (usually github, or else set up your own)

I am using git for small personal projects (2-3 people), where can I find a best practice workflow for syncing changes directly between the team members machines. Alternatively, what are some compelling arguments for why I should avoid this and instead set up a 'central' server?

Thanks,
Ben

回答1:

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.

回答2:

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.

回答3:

You don't necessarily need to put a copy on a physical server somewhere, but it may help to have a 'blessed' repository somewhere -- make one of your team (possibly on a rotation) responsible for collecting and managing people's changes when they are ready to be treated as final. They can either keep a branch in their usual repository or maintain a separate repository on their local system to store the master sources.

As a concrete example, consider Linux and Linus Torvalds -- there's no central repository that everyone pushes to, but Linus maintains a repository which contains all of the code he considers 'ready' (and so do several other people, for different definitions of 'ready'). That way you've got a canonical definition of what code is in, and a place to define what your releases are.

回答4:

You should setup a central server as a social construct, not a technical one, so that everyone knows where to find the latest official version, without any possibility for confusion.

回答5:

As has been mentioned Git works really well without a centralised server. But a good reason to have a central server is to have an "always on" place to push code once a feature is completed that other developers can pull from without having to have access to your local machine.

For example, currently I work on a 3 man dev team. We all work on laptops. We could have a work flow where we just pull from each other's machines. But if I work on a feature and commit my chances after everyone has left the office and I want them to take a look with this system they can't do anything unless my laptop is on and available on the network. If the guys turn up earlier than me (which they always do) they have to wait until my laptop is back online.

If I push to something like BitBucket or GitHub or just an always on server in the office, any of the other developers can simply pull the changes I've made when ever they are next online.

That to me is the main reason to have a central server, and really it isn't a fault with Git but rather a consequence of working with laptops.

回答6:

Have a look at the Git for beginners: The definitive practical guide

section "How do you set up a shared team repository?"

回答7:

Git works pretty well with this sort of setup, although you'll want to avoid pushing changes to someone else's checked out branch ( https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F ). You might have an integration branch that you push code to, and merge other people's changes from.

I think the main reason that a central repo is used a lot is that it can be taken as the canonical base for all your code, whereas it can be a little harder to reason about what you should be merging into when you have 3 or more branches of development going on.