Start on some git-in-baserock documentation.

1 files changed, 44 insertions, 0 deletions

diff --git a/git.txt b/git.txt
new file mode 100644
index 0000000..97e5692
--- /dev/null
+++ b/git.txt
@@ -0,0 +1,44 @@
+An introduction to git
+======================
+
+You are probably familiar with the concept of a `version control system`
+- a repository in which your source code is stored, which keeps track of
+changes made to every file over time. You may be less familiar with the
+concept of a *distributed* version control system. In the traditional
+model, there is one central server holding a master version of your
+software; each developer checks out software to their local machine,
+makes changes to it, and commits it back to the server.
+
+In a distributed version control system, there is no authoritative
+server enforced by software. Each developer has their own repository;
+there may be a master repository (in the case of Baserock, the Trove)
+or indeed a series of repositories accumulating changes by various
+developers to particular subsystems, as in the case of the Linux kernel,
+but this is simply a matter of policy.
+
+Because each developer has their own repository, they do not need 
+continuous network access to work, and because each developer has
+a complete local copy of the whole codebase branches become very fast.
+Consequently, git development revolves much more strongly than most
+version control systems around a model of creating a temporary local 
+branch for a particular bugfix or feature, getting that branch to work 
+correctly, and then merging it into the upstream repository.
+
+Baserock revolves very strongly around this model. The whole Baserock
+system is stored in git. Making changes to your system involves 
+branching your system as a whole, making changes to the components
+of Baserock you want to modify in a local branch in your local
+git repositories, and eventually merging those changes into your
+upstream repository.
+
+Apart from its suitability by design for such a development model,
+and because of its scalability, we use git because it is by far the 
+most popular open source revision control system, making it easy
+to incorporate many upstream components into Baserock; indeed, 
+upstream components not using git are converted to use git in 
+order that Baserock can be a homogenous whole.
+
+
+
+
+