Why does everyone use Git in a centralized manner?

Question

I have used Git at my past two companies for version control. It seems from what I've heard that about 90% of companies use Git over other version control systems.

One of the biggest selling points of Git is that it is decentralized, i.e. all repositories are equal; there is no central repository/ source of truth. This was a feature Linus Torvalds championed.

But it seems that every company used Git in a centralized manner, much like one would use SVN or CVS. There is always a central repository on a server (usually on GitHub) that people pull from and push to. I have never seen or heard of (in my admittedly limited experience) people using Git in the truly decentralized manner in which it was intended, i.e. pushing and pulling to other colleagues repositories as they saw fit.

My questions are:

1. Why don't people use a distributed workflow for Git in practice?
2. Is the ability to work in a distributed manner even important to modern version control, or does it just sound nice?

Edit

I realized I didn't get across the correct tone in my original question. It sounded like I was asking why anyone would work in a centralized manner when a distributed version control system (DVCS) was so obviously superior. In actuality, what I meant to say was, I don't see any benefits to DVCS at all. Yet I often hear people preaching its superiority, while the real-world seems to agree with my view.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

Why does everyone use git in a centralized manner?

We've never met, how comes that you say everyone? ;)

Secondly, there are more other features that you find in Git but not in CVS or SVN. Maybe it's just you assuming that this must be the only feature for everyone.

Sure many people may use it centralized like CVS or SVN. But don't forget the other feature that inherently comes with a ditributed VCS: all copies are more or less "complete" (all branches and the full history is available) and all branches can be checked out without connecting to a server.

I my opinion this is another feature that should not be forgotten.

While you're not able to do this with out of box CVS and SVN, Git can be used centralized like the former ones without any problems.

So I'm able to commit my changes, maybe squash work-in-progress commits together, then fetch and rebase my work onto the main development branch.

Other features that come out of box with Git:

• cryptographically sign commits
• rebasing (reorder and squash commits; edit commits, not only the message)
• cherry picking
• bisecting the history
• local branches and stashing changes (called "shelving" in Wikipedia)

Also see these three tables in Wikipedia - Comparison of version control software:

• Features

• Basic commands

• Advanced commands

So again, maybe the decentralized manner isn't that only feature that make people use it.

1. Why don't people use a distributed workflow for Git in practice?

Anyone contributing to or hosting a bigger project on Bitbucked, GitHub etc. will excactly do that. The maintainers keep the "main" repository, a contributor clones, commits and then sends a pull request.

In companies, even with small projects or teams, a distributed workflow is an option when they either outsource modules and don't want externals to modify the sacred development branch(es) without having their changes reviewed before.

2. Is the ability work in a distributed manner even important to modern version control, ...

As always: it depends on the requirements.

Use a decentralized VCS if any point applies:

• want to commit or navigate the history offline (i.e. finishing the submodule in the mountain cabin during vacation)
• provide central repos but want to keep "the true" repository apart to review changes (i.e. for big projects or distributed teams)
• want to provide (a copy of) the whole history and branches occasionally while preventing direct access to the central repo (similar to the second one)
• want to version something without having to store that remotely or setting up a dedicated repository (especially with Git a mere git init . whould be enough to be ready to version something)

There are some more but four should be enough.

... or does it just sound nice?

Of course it sounds nice - for beginners.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

You are correct. The distributed features of Git are just extra complexity that you will never need.

However, in order to understand where this misguided kind of software came from you first have to understand how people used to work.

As you know, nowadays everyone works on the same machine; we edit files, compile code, and commit on the same box. There is no “my” file or “your” file or “the server’s” file. It’s just “the file”.

But—if you can imagine for a second—people used to work on their own machines. No, not like the dumb terminal you use to connect to HQ in Uzbekistan (from France); they had their own full-fledged “servers” if you will (I forgot what they used to call it) with their own filesystems and even own binaries (programs).

Now, they had the option of using centralized version control systems as well back then—they weren’t total brutes—, but they did have some attempted excuses up their sleeves for using these DVCSs:

• You can look at the history locally instead of round-tripping to the central repository
• You can experiment “privately” (people used to exploit the fact that they had their own machines in order to hide some of what they were doing from other people)
• You have the freedom to take a risk on some path of development which might be a dead end without impacting anyone else
• Fast merges (?)
• No need for centralized locks on files

Well anyway, not to worry, this is just something of historical interest; since we only use one single machine per repository, all of this does not apply anymore.

Answer 14

While it's true that many (if not most) teams use Git in a way that resembles centralized version control systems, there are some key aspects of Git's distributed nature that can be beneficial even in these workflows.

1. Local Operations: With Git, nearly all operations are local, which makes them fast. You have a complete copy of the project history on your local machine, meaning you don't have to communicate with a server to view commit history, create branches, or switch between branches. This not only improves speed, but also makes it possible to work offline.

2. Flexible Workflows: Git's distributed nature makes it flexible in terms of workflows. Teams can structure their use of branches, merges, and forks in a variety of ways to suit their specific processes, team sizes, and project complexities.

3. Redundancy and Data Integrity: Every clone of a Git repository is a full backup of the project and its history. This redundancy is an inherent feature of a distributed system and increases data integrity.

4. Forking: The ability to fork a project (which is often used in conjunction with a centralized repository, like GitHub) is a direct result of Git's distributed nature. This is particularly useful in open source projects where anybody can fork the main repository, work on their own changes and then propose these changes back to the main project via a pull request.

5. Isolated Development: The distributed nature of Git allows developers to experiment with their own versions of the project without interfering with others' work. They can commit changes, and even make mistakes, in their local repository without these impacting the central repository.

So even when used in a centralized way, the underlying distributed nature of Git can still provide advantages. It might be that for many teams the benefits of a centralized model (like easy coordination and clearer access control) are more immediately apparent, while the benefits of a distributed model are subtler or more situational.

Lastly, there's also the issue of industry inertia. Git has become the de facto standard for version control and has a wealth of tooling and resources built around it. So, even if a team doesn't need the distributed aspects of Git, they might use it simply because it's what everyone else uses and it's well supported.

Answer 15

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.

Answer 16

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”.