Merge pull request #1138 from rpjday/ch5

chapter 5: semantic cleanup of first part of chapter 5

Author: ben

book/05-distributed-git/sections/distributed-workflows.asc

@@ -1,18 +1,18 @@
 === Distributed Workflows
 
 (((workflows)))
-Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
-In centralized systems, every developer is a node working more or less equally on a central hub.
-In Git, however, every developer is potentially both a node and a hub -- that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
-This opens a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
+In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
+In centralized systems, every developer is a node working more or less equally with a central hub.
+In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
+This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
 We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.
 
 ==== Centralized Workflow
 
 (((workflows, centralized)))
 In centralized systems, there is generally a single collaboration model -- the centralized workflow.
-One central hub, or _repository_, can accept code, and everyone synchronizes their work to it.
-A number of developers are nodes -- consumers of that hub -- and synchronize to that one place.
+One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
+A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.
 
 .Centralized workflow.
 image::images/centralized_workflow.png[Centralized workflow.]
@@ -23,6 +23,7 @@ This concept is as true in Git as it is in Subversion(((Subversion))) (or any CV
 
 If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
 Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other.
+
 Say John and Jessica both start working at the same time.
 John finishes his change and pushes it to the server.
 Then Jessica tries to push her changes, but the server rejects them.