First thing to say, keeping information in Git is much closer to single-source-of-truth than keeping it only in peoples heads, or on pieces of paper scattered around offices, or on inaccessible/incompatible systems. So in many cases using Git for single source of truth is much of an improvement compared to what was done previously.

But, Git was not designed to be a “single-source-of-truth”. In fact, before the conception of Git but over some time, it was realised that software source code management does not fit in well into the single source of truth idea. The reasons behind are that inevitably multiple versions of software need to be managed if only for testing and experimenting purposes; and that some developments need to be done in long term “branches” of the source code.

This evolution can be seen in the reduction in facilities for “reserved checkouts”, i.e, ways to make sure only one person at a time can modify the source code: the RCS had this facility on by default, in CVS it was optional and by the time of Git it completely disappeared.

And indeed in order to modify a remote Git repository, you need to first create your own local source of truth (and now by definition there are two!) and then try to synchronise the two.

Thinking of the source code repository as a database the design choices for Git can be seen in terms of the CAP theorem: Git maximised the “availability” and “partitioning” arms with the “Consistency” inevitably being lost.

CAP diagram CAP theorem illustrated by a Venn diagram CC BY-SA 4.0 JamieMcCarthy , Wikipedia. Git emphasises the Availability and Partition Tolerance arms.

So Git is, by design, further away from single source of truth than many of the previous version control systems.

Another way of thinking about this in database terms: Git would not be a good way of tracking which seats have been reserved on a particular airline flight, precisely because there is no single source of truth with Git. This is in contrast with conventional on-line DBs which can guarantee seat availability and that each seat is only reserved once.

Perhaps one of the reasons for popularity of services such as GitHub and GitLab is that they do offer something closer to the single source of truth than plain git, but at the cost of course of reducing availability and partionability.