Is Git distributed or decentralized?

Question

I know git used version control to track files. And it is also distributed, meaning more than one computer stores the relevant files. But my doubt is if git is distributed or decentralized? If it is decentralized, then why do we need github, gitlab? using Github and Gitlab makes it distributed(one master multiple slave nodes) right? since, we have a master(like github) from which clients(collaborators) depend on it. But git takes advantage of blockchain(of sorts) technology, which makes me think that git is decentralized, since all the blockchain technology applications like bitcoin, ethereum are decentralized. Unlike bitcoin, there is no peer-to-peer communication within the nodes in git, which contradicts the decentralized nature of blockchain. We need github to communicate with the other nodes or if we were to collaborate with others. please someone tell me if git is distributed or decentralized?

Answer 1

Git is both (and it is neither).

It is distributed...

...in the sense that anyone with a clone of a particular repository is theoretically "equal" to any other developer with a clone of the same repo. One of the main reasons this approach is used is to allow any developer to continue their work without the need to always be connected to a centralized master server. If you have your own complete copy, and it's "equal" to any other, you can develop against it and sync up later.

It is decentralized....

...mainly for the same reason given above. One of the core concepts is that there is no "main" server. The problem with that is, in many situations (like a software engineer for a large company), there really is a need to have a centralized master. It's not that Git isn't meant for this type of workflow (clone --> develop --> commit --> push to central repo), but rather that it doesn't force it upon you. Since that has been such a ubiquitous way of working, it's become the norm to use GitHub on top of Git to provide the desired structure to enable this type of development cycle.

It is neither?

Because it doesn't force you to use any specific workflow model, it is perhaps also reasonable to conclude that Git is neither distributed nor decentralized: it largely transcends these implementation details, allowing users to use it however they wish. It includes functionality that is abstract and flexible to such an extent that it can fit into almost any workflow, but how that works is left for the users to decide. This is also one of the main reasons why Git is so difficult for newcomers to learn.

So just remember that Git and GitHub are not the same. Git is a version control tool, and GitHub is a collaboration tool that happens to use Git, and provides a framework for a specific type of development cycle that is very well established and familiar to many people.

Also, git can communicate with any host, it is in no way dependent on GitHub to provide centralization, even though we often treat it as if that were the case. Git can use SSH, HTTP(S), and even it's own proprietary protocol to push and fetch data from a repo on any other system, provided the user has the ability to log in to that host.

What about Blockchain?

Git does use the same underlying data structure— called a hash tree (or Merkle tree)— as many common blockchain implementations (ex: Bitcoin, Ethereum). What is more, both git and blockchain have some very similar requirements: they both seek to be decentralized and distributed. But how those features fit into the overall purpose of the two technologies is quite different.

With blockchain, the notion of decentralization is heavily focused on the need to maintain consensus: it is of fundamental importance to the integrity of the blockchain that the majority of the nodes agree on the content of the ledger that they are building. That is because each entry is predicated on the correctness of the previous one. Without consensus, the overall usefulness of a blockchain is unclear.

Compare that to Git, and while some might argue that consensus is also important in maintaining the integrity of a repository, it is not so intrinsic to the general usefulness of Git as a tool. Two clones of the same repo can become massively out of sync without diminishing my ability to use either (or both) of them for version control. It also doesn't preclude my ability to utilize parts of both, as long as I don't mind doing some manual merging. Git even allows for some very extensive "tree surgery" wherein I can freely rewrite history, picking pieces from different sources (even sources without a common ancestor) and stitching them together, ex post facto, to create a chain of events that is pure fiction.

So while these two technologies have some superficial similarities— and some that are a bit deeper, too— they serve different purposes and have their own unique design requirements, and as such they are not directly comparable to one another.