From 2b5de6c9c4121f5842aacda166f38d05652b2cdf Mon Sep 17 00:00:00 2001 From: Joel Dillon Date: Tue, 11 Sep 2012 13:52:09 +0100 Subject: Start on some git-in-baserock documentation. --- git.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 git.txt 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. + + + + + -- cgit v1.2.1