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:
- Why don't people use a distributed workflow for Git in practice?
- 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.
Best Answer
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.