dev-manual: Edits to "Workflows" section.

(From yocto-docs rev: 6b076afb92454b8a7279f747a78bbf565a93c09d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 24 insertions, 20 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index a365e07f1d..7eb751aa81 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -1084,7 +1084,7 @@
         tracks every change and whose structure provides branches for all diverging functionality.
         Although there is no need to use Git, many open source projects do so.
         For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
-        branch of the Git repository.
+        branch of a given Git repository.
         The "master" branch is the “upstream” repository where the final builds of the project occur.
         The maintainer is responsible for allowing changes in from other developers and for
         organizing the underlying branch structure to reflect release strategies and so forth.
@@ -1094,7 +1094,7 @@
     </para>
 
     <para>
-        The project also has contribution repositories known as “contrib” areas.
+        The project also has contribution repositories known as "contrib" areas.
         These areas temporarily hold changes to the project that have been submitted or committed
         by the Yocto Project development team and by community members that contribute to the project.
         The maintainer determines if the changes are qualified to be moved from the "contrib" areas
@@ -1105,7 +1105,7 @@
         Developers (including contributing community members) create and maintain cloned repositories
         of the upstream "master" branch.
         These repositories are local to their development platforms and are used to develop changes.
-        When a developer is satisfied with a particular feature or change, they “push” the changes
+        When a developer is satisfied with a particular feature or change, they "push" the changes
         to the appropriate "contrib" repository.
     </para>
 
@@ -1113,14 +1113,14 @@
         Developers are responsible for keeping their local repository up-to-date with "master".
         They are also responsible for straightening out any conflicts that might arise within files
         that are being worked on simultaneously by more than one person.
-        All this work is done locally on the developer’s machine before anything is pushed to a
+        All this work is done locally on the developer’s machines before anything is pushed to a
         "contrib" area and examined at the maintainer’s level.
     </para>
 
     <para>
         A somewhat formal method exists by which developers commit changes and push them into the
         "contrib" area and subsequently request that the maintainer include them into "master"
-        This process is called “submitting a patch” or “submitting a change.”
+        This process is called “submitting a patch” or "submitting a change."
         For information on submitting patches and changes, see the
         "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section.
     </para>
@@ -1150,7 +1150,7 @@
                 to more easily include or refuse changes.</para>
                 <para>It is also good practice to leave the repository in a state that allows you to
                 still successfully build your project.  In other words, do not commit half of a feature,
-                then add the other half in a separate, later commit.
+                then add the other half as a separate, later commit.
                 Each commit should take you from one buildable project state to another
                 buildable state.</para></listitem>
             <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
@@ -1158,25 +1158,27 @@
                 You can name these branches anything you like.
                 It is helpful to give them names associated with the particular feature or change
                 on which you are working.
-                Once you are done with a feature or change, simply discard the branch.</para></listitem>
+                Once you are done with a feature or change and have merged it 
+                into your local master branch, simply discard the temporary 
+                branch.</para></listitem>
             <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
                 command allows you to take the
                 changes from one branch and fold them into another branch.
                 This process is especially helpful when more than a single developer might be working
                 on different parts of the same feature.
-                Merging changes also automatically identifies any collisions or “conflicts”
+                Merging changes also automatically identifies any collisions or "conflicts"
                 that might happen as a result of the same lines of code being altered by two different
                 developers.</para></listitem>
             <listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should
                 use a system where branches indicate varying levels of code readiness.
-                For example, you can have a “work” branch to develop in, a “test” branch where the code or
-                change is tested, a “stage” branch where changes are ready to be committed, and so forth.
+                For example, you can have a "work" branch to develop in, a "test" branch where the code or
+                change is tested, a "stage" branch where changes are ready to be committed, and so forth.
                 As your project develops, you can merge code across the branches to reflect ever-increasing
                 stable states of the development.</para></listitem>
             <listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the
-                concept of developers “pushing” local commits to a remote repository, which is
+                concept of developers "pushing" local commits to a remote repository, which is
                 usually a contribution repository.
-                This workflow is also based on developers “pulling” known states of the project down into their
+                This workflow is also based on developers "pulling" known states of the project down into their
                 local development repositories.
                 The workflow easily allows you to pull changes submitted by other developers from the
                 upstream repository into your work area ensuring that you have the most recent software
@@ -1184,19 +1186,21 @@
                 The Yocto Project has two scripts named <filename>create-pull-request</filename> and
                 <filename>send-pull-request</filename> that ship with the release to facilitate this
                 workflow.
-                You can find these scripts in the local Yocto Project files Git repository in
-                the <filename>scripts</filename> directory.</para>
-                <para>You can find more information on these scripts in the
-                "<link linkend='pushing-a-change-upstream'>Using
-                Scripts to Push a Change Upstream and Request a Pull</link>" section.
+                You can find these scripts in the <filename>scripts</filename>
+                folder of the 
+                <link linkend='source-directory'>Source Directory</link>.
+                For information on how to use these scripts, see the 
+                "<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
                 </para></listitem>
             <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
                 maintainer through an email that you have a change (or patch) you would like considered
                 for the "master" branch of the Git repository.
-                To send this type of change you format the patch and then send the email using the Git commands
+                To send this type of change, you format the patch and then send the email using the Git commands
                 <filename>git format-patch</filename> and <filename>git send-email</filename>.
-                You can find information on how to submit changes
-                later in this chapter.</para></listitem>
+                For information on how to use these scripts, see the 
+                "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>