mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-18 12:32:12 +02:00
Code Issues Packages Projects Releases Wiki Activity

dev-manual: Edits to "Workflows" section.

Browse Source 
(From yocto-docs rev: 6b076afb92454b8a7279f747a78bbf565a93c09d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2013-04-09 15:02:09 -07:00
committed by Richard Purdie
parent 78ec6f7c07
commit 6fedf7b147
1 changed files with 24 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
documentation/dev-manual/dev-manual-newbie.xml
View File

@@ -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>