[ale] Central git repository with multiple users

[Andrew Grieser]

Thanks for the input, I'll try to answer a few questions here.

Michael B. Trausch wrote:
> I'm assuming that it has to be locally hosted due to some sort of
> privacy concerns?  If that is the case, did you know that GitHub
> also has the ability to host private projects?

I had initially wanted to use a GitHub private project, but that was a no-go. I would say the reason it has to be hosted locally is political (meaning: no logical, technical, or legal arguments were made or considered).


Ed Cashin wrote:
> I guess somebody's bound to say it, so I might as well: That's at
> odds with the design philosophy of git, which was created for multiple
> developers who would each have a clone of the repository, and who
> would pull from one another at will, after communicating about the
> changes.
 
Sort of. It's certainly being used differently than how linux kernel developers use it, but the project it's being used for is vastly different than the linux kernel in terms of organization, number and type of developers etc.

> Using a distributed system like git in this way helps the flow of
> changes to reflect the human relationships.  If that isn't desirable,
> maybe svn would be a better choice, since it was created for
> people seeking to do what you appear to be interested in doing.

I don't think subversion is even an option. We make extensive use of branching and merging, which would be nearly impossible with subversion. Plus, subversion is too centralized.

With this setup, everyone still has their own repo on their own computer. That way they can handle their own branching and merging, and work offline without a problem. When they "push", it updates the central copy based on their master branch. That way everyone else can simply "pull" the central copy to get the most up-to-date version.

For a small/coordinated group of developers, I've found this works well. For a project that moves quickly I like having a single central repository that you can pull from to get the most up-to-date version, rather than each developer publishing their own git repository, then having to pull from half a dozen people.

So when you're ready to mainline some code, you just merge it from one of your side branches into the master branch, then push to the central repo, and everyone will have access to it.

I like the fact that revision control systems are becoming more flexible, because there is no one best solution. Certainly, this approach would fail miserably with a large group of developers, and even more-so with the kernel where there are a large number of developers acting mostly independently.

> I guess that just begs the question, "Are there any good tutorials
> on using git in the central repository model?"

None that I've come across. I used to be big into bazaar, which I think has really great documentation. Bazaar documents different workflow scenarios, and how to set those up. The same ideas apply to git. According to their docs, we are using the "decentralized with shared mainline" strategy.

See:
http://bazaar-vcs.org/Documentation

or:
http://bazaar-vcs.org/Workflows

Andrew