Is using a central repository going against GIT's purpose?

Question

If you are in a corporate setting with many people working on a particular application, is it going against the grain of a distributed version control system to have an official central repository?

Sometimes I struggle to understand the concept of a distributed version control system such as GIT in a corporate environment. If you didn't have a central repository, wouldn't it be a PITA to figure out who had the latest updated version to pull from, who has feature x or bug fix y that everyone needs to grab, etc, etc.

Is it defeating the purpose of GIT to use it in a similar fashion to SVN, with a central repository that everyone pushes/pulls from? Every time I think about doing that I feel like I'm missing the point of everything.

Could someone enlighten me?

Answer 1

Not really. DCVS just allows more freedom in how to interact between developers without involving the central repository. The official repository is only official by consensus. Linux also has a central repository, the one from which the "official" kernel-releases are created, but there is no physical difference between the central, "official", repository and client repositories as it is in centralized VCS.

Answer 2

If you check this Presentation of Git, (slide 475 and following), a Central repository Model is perfectly supported by Git.

You can can force anyone wishing to git push its development to first make a git fetch + git merge first, then push.

That does not defeat the purpose of Git at all, and ensure everyone is 'in sync' with each other.

The difference with the Linus's "official" repository mentionned by JesperE is that it is managed by a different workflow, namely a "Dictator and lieutenants" model, where write access (push) is only granted for Linus, and read are granted for anyone.

Now: "does that defeat the point of DVC" ?

No, you still have distributed repositories, one for each developers, and they can fetch/merge between their own repositories, according to their own internal team workflow.
However, if they want to contribute to the central repo, they need to have to be first up-to-date with the latest history of that repository.

Answer 3

With distributed source control, a central "official" repository is established by policy - not source control tool architecture.

Answer 4

DVCS like Git don’t force you to use a central repository. Of course it’s possible to declare one repository to be “central” or “official” or whatever, and in a company context a central repository makes some sense—if not for development then at least for backup purposes.

Answer 5

Definitely not defeating the purpose of Git.

The advantage to using Git or any other DVCS even when there is a central, official, repository is still that the source control is decentralised. That is, you can take your copy of the repository, work on your code, and do a local commit every few minutes if you need. You don't need to worry that the commits are on half-finished code that break the build, it's all local. (And very fast.)

Then when all the work is done, you can clean up the history and push the completed changes to the central repository in a homogeneous, clean, state.

I don't think you can underestimate the advantage of separating the idea of "private" commits and "public" pushes. It allows changes to be tracked even though you're the only one to benefit from such small granularity.

Answer 6

One of the main benefits of DVCS is that you can get the latest version from the 'official' repository and then be adventurous with it. You can commit changes locally and roll back at will. This also means you can even work even without access to the central repositoy and still have the benefits of source code control.

I think with a bit of discipline the model works very well. This article explains well the various models you could adopt

Answer 7

A central server in a DVCS is not a technical requirement but in a corporate setting it is an administrative requirement.