mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-02 13:29:49 +00:00
Code Issues 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
documentation/dev-manual/dev-manual-newbie.xml
+24 -20
View File
@@ -1084,7 +1084,7 @@
tracks every change and whose structure provides branches for all diverging functionality. 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. 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" 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 "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 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. organizing the underlying branch structure to reflect release strategies and so forth.
@@ -1094,7 +1094,7 @@
</para> </para>
<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 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. 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 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 Developers (including contributing community members) create and maintain cloned repositories
of the upstream "master" branch. of the upstream "master" branch.
These repositories are local to their development platforms and are used to develop changes. 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. to the appropriate "contrib" repository.
</para> </para>
@@ -1113,14 +1113,14 @@
Developers are responsible for keeping their local repository up-to-date with "master". 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 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. 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. "contrib" area and examined at the maintainer’s level.
</para> </para>
<para> <para>
A somewhat formal method exists by which developers commit changes and push them into the 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" "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 For information on submitting patches and changes, see the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section. "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section.
</para> </para>
@@ -1150,7 +1150,7 @@
to more easily include or refuse changes.</para> 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 <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, 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 Each commit should take you from one buildable project state to another
buildable state.</para></listitem> buildable state.</para></listitem>
<listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and <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. You can name these branches anything you like.
It is helpful to give them names associated with the particular feature or change It is helpful to give them names associated with the particular feature or change
on which you are working. 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> <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
command allows you to take the command allows you to take the
changes from one branch and fold them into another branch. changes from one branch and fold them into another branch.
This process is especially helpful when more than a single developer might be working This process is especially helpful when more than a single developer might be working
on different parts of the same feature. 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 that might happen as a result of the same lines of code being altered by two different
developers.</para></listitem> developers.</para></listitem>
<listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should <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. 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 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. 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 As your project develops, you can merge code across the branches to reflect ever-increasing
stable states of the development.</para></listitem> stable states of the development.</para></listitem>
<listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the <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. 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. local development repositories.
The workflow easily allows you to pull changes submitted by other developers from the 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 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 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 <filename>send-pull-request</filename> that ship with the release to facilitate this
workflow. workflow.
You can find these scripts in the local Yocto Project files Git repository in You can find these scripts in the <filename>scripts</filename>
the <filename>scripts</filename> directory.</para> folder of the
<para>You can find more information on these scripts in the <link linkend='source-directory'>Source Directory</link>.
"<link linkend='pushing-a-change-upstream'>Using For information on how to use these scripts, see the
Scripts to Push a Change Upstream and Request a Pull</link>" section. "<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
</para></listitem> </para></listitem>
<listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the <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 maintainer through an email that you have a change (or patch) you would like considered
for the "master" branch of the Git repository. 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>. <filename>git format-patch</filename> and <filename>git send-email</filename>.
You can find information on how to submit changes For information on how to use these scripts, see the
later in this chapter.</para></listitem> "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section.
</para></listitem>
</itemizedlist> </itemizedlist>
</para> </para>
</section> </section>