Fuchsia manages commits through Gerrit at https://fuchsia-review.googlesource.com.
To submit your contribution to the Fuchsia project, follow the instructions in the sections below.
Before you submit your first contribution to the Fuchsia project, you need to sign the Google Contributor License Agreements (CLA) and generate a cookie to authenticate you in Gerrit.
To sign the Google CLA, do the following:
To generate the cookie, do the following:
Follow these steps to create a Change in Gerrit:
Create a new branch:
git checkout -b <branch_name>
Create or edit files in the new branch.
Add the changes:
git add <files>
Commit the changes (see Add commit message tags):
Upload the changes to Gerrit:
If you want to use the
git command instead, run the following command:
git push origin HEAD:refs/for/master
Note: If you want to upload the changes with a custom topic, see Upload changes from multiple repositories for details.
At any time, if you want to make changes to your patch, use
git commit --amend
Once the change is submitted, clean up the branch:
git branch -d <branch_name>
See the Gerrit documentation for more information.
You must include
[tags] in the subject of a commit message to indicate which module, library, and app are affected by your Change.
See the following example of a commit message, which shows the tags in the subject:
[parent][component] Update component in Topaz. <The details of the commit message here.> Test: Added test X
For the tags, use
[docs] for documentation,
[zircon] for zircon,
[fidl] for FIDL, and more. You can view the commit history of the files you've edited to check for the tags used previously.
See these examples:
Note: Gerrit flags your Change with
Needs Label: Commit-Message-has-tags if the subject of the commit message doesn't include tags.
If a change requires non-obvious manual testing for validation, those testing steps should be described in a line in the change description beginning with
If the instructions are more elaborate, they can be added to a linked bug. If the change does not intend to change behavior, the commit message should indicate as such.
In some cases, we are not able to test certain behavior changes because we lack some particular piece of infrastructure. In that case, we should have an issue in the tracker about creating that infrastructure and the test label should mention the bug number in addition to describing how the change was manually tested:
Test: Manually tested that [...]. Automated testing needs US-XXXX
Developers are responsible for high-quality automated testing of their code. Reviewers are responsible for pushing back on changes that do not include sufficient tests.
Note: See Fuchsia testability rubrics for more information on how to introduce testable and tested code in the Fuchsia project.
origin/master, which reveals the files that cause merge conflicts:
git rebase origin/master
Edit those files to rsesolve the conflicts and finish the rebase:
git add <files_with_resolved_conflicts> git rebase --continue
Commit and upload your changes:
git commit --amend jiri upload
To understand how to manage changes that span different repositories (petals), see the following pages:
More information on the structure of the
fuchsia.git respository is available in Source code layout.