diff options
author | Joel Dillon <joel.dillon@codethink.co.uk> | 2012-09-11 13:59:32 +0100 |
---|---|---|
committer | Joel Dillon <joel.dillon@codethink.co.uk> | 2012-09-11 13:59:32 +0100 |
commit | 9c9bf556dab8b07d1afd4fcf7bdedafffb2a381c (patch) | |
tree | 800fc950eef68569e06fb8a83235357cda4ec96c | |
parent | 2b5de6c9c4121f5842aacda166f38d05652b2cdf (diff) | |
download | documentation-9c9bf556dab8b07d1afd4fcf7bdedafffb2a381c.tar.gz |
Improve wording a bit
-rw-r--r-- | git.txt | 10 |
1 files changed, 7 insertions, 3 deletions
@@ -22,14 +22,18 @@ 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. +correctly, and then merging it into the upstream repository; +therefore, as well as fast branching it also has very powerful support +for merging. -Baserock revolves very strongly around this model. The whole Baserock +Baserock is designed to take full advantage of this. 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. +upstream repository. Part of Baserock's power is in its ability +to automate the process of branching every component in +your system as you work on them. 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 |