Ahh, but in fact you are using git in a decentralized manner!

Let us compare git's predecessor in mindshare, svn. Subversion had only one "repo", one source of truth. When you did a commit, it was to a single, central repo, to which every other developer was committing as well.

This sort of worked, but it led to numerous problems, the biggest one being the dreaded merge conflict. These turned out to be anywhere from annoying to nightmarish to resolve. And with one source of truth, they had a nasty habit of bringing everyone's work to a screeching halt until they were resolved. Merge conflicts certainly exist with git, but they are not work-stopping events and are much easier and faster to resolve; they generally affect only the developers involved with the conflicting changes, rather than everyone.

Then there is the whole single-point-of-failure, and the attendant problems that brings. If your central svn repo dies somehow, you're all screwed until it can be restored from backup, and if there were no backups, you're all doubly screwed. But if the "central" git repo dies, you can restore from backup, or even from one of the other copies of the repo which are on the CI server, developers' workstations, etc. You can do this precisely because they are distributed, and each developer has a first-class copy of the repo.

On the other hand, since your git repo is a first-class repo in its own right, when you commit, your commits go to your local repo. If you want to share them with others, or to the central source of truth, you must explicitly do this with a push to a remote. Other developers can then pull down those changes when it's convenient for them, rather than having to check svn constantly to see if someone's done something that will screw them up.

The fact that, instead of pushing directly to other developers, you push changes to them indirectly via another remote repo, doesn't matter much. The important part from our perspective is that your local copy of the repo is a repo in its own right. In svn, the central source of truth is enforced by the design of the system. In git, the system doesn't even have this concept; if there is a source of truth, it is decided externally.

When your build server (you are using CI, right?) creates a build, where does it pull from? Sure, an integration build you could argue does not need "one true repo" but surely a distribution build (i.e. what you give to the customer) does.

In other words: fragmentation. If you designate one repo as "the" repo and appoint guardians who vet pull requests, you have an easy way to satisfy the request of "give me a software build" or "I am new to the team, where is the code?"

The strength of DVCS is not so much the peer-to-peer aspect of it, but the fact that it is hierarchical. I modify my workspace, then I commit to local. Once I have a feature complete, I merge my commits and push them to my remote. Then anyone can see my tentative code, provide feedback, etc. before I create a pull request and a project admin merges it into the One True repo.

With traditional CVCS you either commit or you don't. That is fine for some workflows (I use both VCS types for different projects), but falls flat on its face for a public or OSS project. The key is DVCS has multiple steps, which are more work, but provide a better way to integrate code from strangers through a built-in process that allows better visibility into what is being checked in. Using it in a centralized manner means you can still have that gold standard of the current state of the project while also providing a better code sharing mechanism.

I don't know how you define "everyone", but my team has "a central repo on a server" and also from time to time we pull from other colleagues' repos without going via that central repo. When we do this we do still go via a server, because we choose not to email patches about the place, but not via the central repo. This generally happens when a group is collaborating on a particular feature and wants to keep up to date with each other, but as yet has no interest in publishing the feature to everyone. Naturally since we aren't secretive silo-workers those situations don't last long, but DVCS provides the flexibility to do whatever is most convenient. We can publish a feature branch or not according to taste.

But 90%+ of the time, sure, we go via the central repo. When I don't care about any particular change or particular colleague's work it's more convenient, and it scales better, to pull "all my colleagues' changes that have been vetted in the central repo", rather than separately pulling changes from each of N colleagues. DVCS isn't trying to prevent "pull from main repo" being the most common workflow, it's trying to prevent it being the only available workflow.

"Distributed" means that all repos are technically equivalent as far as the git software is concerned, but it doesn't follow that they all have equal significance as far as developers and our workflows are concerned. When we release to clients or to production servers, the repo we use to do that has a different significance from a repo used only by one developer on their laptop.

If "truly decentralized" means "there are no special repos" then I don't think that's what Linus means to champion, given that in point of fact he does maintain special repos that are more important in the grand scheme of things, than is some random clone of Linux that I made yesterday and plan to use only to develop some little patch and then delete it once he's accepted the patch. git doesn't privilege his repo over mine, but Linus does privilege it. His "is the current state of Linux", mine isn't. So naturally changes tend to go through Linus. The strength of DVCS over centralized VCS isn't that there must not be a de facto centre, it's that changes don't have to go through any centre because (conflicts permitting) anyone can merge anything.

DVCS systems are also forced, because they are decentralized, to provide certain convenient features based around the fact that you necessarily must have a complete history (i.e. a repo) locally in order to do anything. But if you think about it there's no fundamental reason why you couldn't configure a centralized VCS with a local cache that keeps the whole history for read-only operations permitted to be out of date (I think Perforce has an option for this mode, but I've never used Perforce). Or in principle you could configure git with your .git/ directory on a remote-mounted filesystem in order to emulate the "feature" of SVN that it doesn't work when you don't have a network connection. In effect, DVCS forces the plumbing to be more robust than you can get away with in a centralized VCS. This is a (very welcome) side effect and helped motivate DVCS design, but this distribution of responsibility at the technical level isn't the same as fully decentralizing all human responsibility.

The interesting thing about the nature of DVCS, is if other people are using it in a distributed manner, you likely wouldn't know it unless they are interacting directly with you. The only thing you can say definitively is that you and your direct teammates don't use git this way. This doesn't require a company-wide policy. So I will ask you, why don't you use git in a decentralized manner?

To address your edit, perhaps you need some experience working with an actual centralized version control to appreciate the differences, because although they may seem subtle, they are pervasive. These are all things my team actually does at work that we couldn't do when when we had centralized VCS:

• Have a very small list of core developers with commit access to the "central" repo for each microservice. Everyone else can work out of forks and submit via pull requests.
• Can commit much more frequently, usually several times per hour versus once or twice per day.
• Can create branches for any reason to coordinate temporarily with coworkers, and push to it and pull from it several times per day, then squash it when ready to share with a larger group. Do you have any idea how hard it is to get permission to create a temporary branch for something like this in a traditional CVCS?

At the risk of sounding old for saying it, you really don't know how easy you have it.

Ultimately, you are building a product. This product represents your code at a single point in time. Given that, your code must coalesce somewhere. The natural point is a ci server or central server from which the product is built, and it makes sense that this central point is a git repository.

I think you're question comes from an (understandable) always connected mindset. i.e. The central 'truth' ci server is always (or near always) available. While this is true in most environments, I have worked in at least one which was far from this.

A Military Simulation project my team worked on several years ago. All the code (We're talking a >US$1b codebase) had to (by law/international agreement, men in dark suits come if you don't) be on machines physically isolated from any Internet connection. This meant the usual situation of we each had 2 PCs, one for writing/running/testing the code, the other to Google things, check E-mail and such. And there was a local network within the team of these machines, obviously not in any way connected to the Internet.

The "central source of truth" was a machine on an army base, in an all-cinderblock underground windowless room (reinforced building, yada-yada). That machine also had no Internet connection.

Periodically, it would be someone's job to transport (physically) a drive with the git repo (containing all our code changes) to the army base - which was several hundred kilometers away, so, you can imagine.

Moreover, in very large systems where you have lots of teams. They will generally each have their own "central" repo, which then goes back to the actual (god tier) "central" central repo. I know of at least 1 other contractor who did the same hard-drive git repo dash with their code too.

Also, if you consider something on the scale of the Linux kernel... Developers don't just send a pull request to Linus himself. It's essentially a hierarchy of repo's - each of which was/is "central" to someone/some team.

The disconnected nature of git means that it can be used in environments where connected model source-control tools (i.e. SVN, for one) couldn't be used - or couldn't be used as easily.

The distributed aspect of a DVCS shows up in open source development all the time, in the form of forking. For example, some of the projects I contribute to were abandoned by the original author and now have a bunch of forks where the maintainers sometimes pull specific features from one another. Even in general, OSS projects take outside contributions via pull request, rather than by granting random people push access to the ground-truth repo.

This isn't a very common use case when building a concrete product with a specific official release, but in the F/OSS world it's the norm, not the exception.

Flexibility is a curse as well as a blessing. And as Git is extremely flexible, it's almost always far too flexible for the typical situation. Specifically, most Git projects aren't Linux.

As a result, the smart choice is to remove some of that theoretical flexibility when implementing Git. In theory repositories can form any graph, in practice the usual choice is a tree. We can see the clear benefits using graph theory: in a tree of repositories, any two repositories share exactly one ancestor. In a random graph, the idea of an ancestor doesn't even exist!

Your git client however almost certainly defaults to the "single ancestor" model. And graphs in which nodes have a single ancestor (except for a root node) are exactly trees. So your git client itself defaults to the tree model, and therefore centralized repositories.

Business logic rewards a centralized server. For nearly all realistic business scenarios, a centralized server is a fundamental feature of the workflow.

Just because you have the capacity to do DVCS doesn't mean your primary work flow has to be DVCS. When I use git at work, we use it in a centralized manner, except for those strange odd cases where the distributed bit was essential to keeping things moving along.

The distributed side of things is complicated. Typically you want to keep things smooth and easy. However, by using git you ensure that you have access to the distributed side to deal with the gnarly situations that may arise down the road.

For a coworker to pull from a git repo on my machine means I need to have a git daemon running at root level as a background task. I am very leery of daemons running on my own computer, or on my company-provided laptop. The easiest solution is "NO"! For a coworker to pull from a git repo on my machine also means my internet address needs to be fixed. I travel, I work from home, and I occasionally work from my office.

On the other hand, VPNing to the corporate site and pushing an branch to the central repo takes less than a minute. I don't even need to VPN in if I'm in the office. My coworkers can easily pull from that branch.

On the third hand, my local git repo is a full-featured repository. I can commit new work, create a new branch for experimental work, and revert work when I make a mess of things, even when I'm working in an airplane flying at 30,000 feet over the middle of nowhere. Try doing that with a centralized version control system.

Complexity:

With a central repository, a typical work flow might be

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

The complexity with respect to the number of developers in O(1).

If instead each developer has their own master branch it becomes, for developer 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

The peer-to-peer approach is O(N).

Consistency:

Now consider if there is a merge conflict between Alice's master branch and Bob's master branch. Each of the N developers could resolve the conflict differently. Result: chaos. There are ways of achieving eventual consistency, but until that happens, all sorts of developer time can be wasted.

Simple:

Companies are centralized organizations, with centralized workflow.

Every programmer has a boss and he has his boss, etc up to CTO. CTO is the ultimate source of technical truth. Whatever tool company uses, it must reflect this chain of command. A company is like an army - you can't let privates outvote a general.

GIT offers features that are useful to the companies (eg. pull requests for code review) and that alone makes them switch to GIT. The decentralized part is simply a feature they don't need - so they ignore it.

To answer your question: The distributed part is indeed superior in distributed environment, eg open-source. Results vary depending on who's talking. Linus Torvalds is not exactly your cubicle rat, that's why different features of GIT are important to him than to your github-centric company.

Maybe it is because he payroll processing is centralized, so we have to keep a central person happy if we wish to get paid.

Maybe it is because we are creating one product, so we need a master copy of the software for the customers.

Maybe it is because it is a lot easier for a programmer to go to one place to get everyone’s changes, rather than having to connect to lots of different machines.

Maybe it is because the bug database is centralized, and must be kept in sync with the code.

Being centralized is great, until there is a problem…..

Git being a distributed system allows a new centre to be created at low cost from any up-to-date repository (just expose the repository to the network). Git also allows an out of date backup to be updated from the repositories on developer machines, so making it easier to recover the centre.

Being able to do merge etc on a local copy of a repository when the network is down is great, but does not need a distributed system; it just needs a system that keeps a local copy of all the data. Likewise with checking in code with flying etc.

At the end of the day there is little cost for being distributed and some benefits. Most of the cost of being distributed is in area that are needed if you want great tracking of branches etc. If you were to design a system for usage in most companies you would not design it to be distributed, as centralized control of the source code is clearly the primary “use case”.