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.
Sign the Google CLA
To sign the Google CLA, do the following:
- Go to the Google Developers' Contributor License Agreements page.
- Sign the agreement on behalf of Only Yourself or Your Employer.
Generate a cookie
To generate the cookie, do the following:
- Log into Gerrit.
- At the top of https://fuchsia.googlesource.com, click Generate Password.
- Copy the generated code and run it in a terminal of your workstation.
Create a Change in Gerrit
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
gitcommand instead, run the following command:
git push origin HEAD:refs/for/master
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.
Add commit message tags
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:
Add test instructions
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.
Resolve merge conflicts
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
Manage changes that span multiple repositories
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.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.