Why git is called a distributed source control system?

Question

It seems after committing code to the local repository, every programmer will run the command.

git push origin master

to push the local file to

Answer 1

It is called distributed because every git working directory contains a full-fledged repository containing complete history of the tree. This also means that you actually do not need network access for development because your tree can essentially be the master tree.

Answer 2

Short Answer

It is not different with client/server model except a local copy, so why is it called a "distributed" one?

In the diagram below alice and david can interact because the system is distributed.

Distributed Version Control

Notice how, say, alice and david can interact because each can act as a server.

Central Version Control

Here the dev team only interacts with the main server.

---

Long Answer

Traditionally speaking source control systems were designed as server-client setups, loosely speaking. So the repository was centrally located.

With git and Mercurial, the system is designed to put all users at equal footing. Everyone has the full repository with them. The control and repository in that way is distributed amongst it users.

Answer 3

Check out the definition of a distributed system and compare that to what Git does/allows to be done. I think there's a match. A client/server approach needs by definition one "definitive/reference copy" which is not the case with Git and similar.

Answer 4

Because your clone can be someone else's master, and you can push your clone towards any other repository. There is no need for a concept of one "true" master; you can run it as a distributed grid of repositories.

Answer 5

Tools such as CVS and SVN offer a centralised repository model. Everybody commits their changes to the same central repository. Each committer keeps a copy of the latest version of the central repository. When they commit changes they send that change back to the main repository.

The limitations here are that you always need to have the latest code on your local repository, and to see the history of changes you will need to ask the server for that information. You also always need to be able to access the remote repository to commit.

A distributed SCN can emulate this model, but it offers so much more. Instead of just having one central repository that you send changes to, every committer has their own repository that has the entire commit history of the project. You don't need to connect to a remote repository, the change is just recorded on your local repository. You can still push to a centralised repository but you don't need to.

(Source: Pragmatic Version Control using Git by Travis Swicegood)

One big benefit of this is that you can start a repository at any time on your local computer. Generally when ever I start a new project I'll git init and start committing updates straight away. Later on if I decide I want to share this project with another developer I can easily set up a centralised repository that we can both access. Or it might never leave my computer but I'll have local version control in place and can easily view my commit history.

Another big benefit (perhaps less so with cloud computing now) is redundancy. If one copy of the repository is lost for whatever reason, any of the other repositories will contain the complete history so you could only potentially lose any work since your last push.

There's some more information on Wikipedia: Distributed revision control

I'd also highly recommend the above mentioned Pragmatic Programmers book on Git.