工作流程提示
这份清单有助于你提高工作效率 在 Fuchsia 上。
安装 Gerrit Monitor
安装 Gerrit Monitor 此 Chrome 扩展程序会包含一系列 Gerrit 更改， 。
优化您的 Gerrit 设置
查看 Gerrit 设置 然后根据自己的喜好加以调整 例如，您可以启用“推送评论时发布评论”， 发布新的补丁集时自动发送草稿注释，而不是 您需要通过网页界面手动创建
在 Git 中启用三向差异比较
默认情况下，Git 在出现冲突时会使用双向 diff。它不会 显示冲突之前的原文，这使得很难 以解决某些冲突。
您可以通过启用三向差异比较来将 Git 配置为显示原始文本：
git config --global merge.conflictstyle diff3
启用特定于 fuchsia 的 Git 命令
将 $FUCHSIA_DIR/scripts/git 添加到 PATH，以便能够使用特定于紫红色的 git
git fuchsia-review [<commit ref>] 等命令，
或 Gerrit 中的给定提交。
问题和解答
建议您在此处添加自己的问题（和答案）！
问：Fucsia 是否有标准的 Git 工作流？
Fuchsia 团队使用多种工作流程。每日 可帮助您上手的工作流程如下：
$ jiri update -gc
# Start a new feature on a `myfeature` branch from the current stable commit
$ git checkout -b myfeature JIRI_HEAD
# Do work, making changes, etc.
$ git commit
# Upload your work to Gerrit for review
$ jiri upload
# OR
$ git push origin HEAD:refs/for/main
恭喜，您已完成第一项 Gerrit 更改！
假设您要在 otherfeature 分支上开始新工作
等待对已找到的作品进行审核时
在您的 myfeature 分支上执行以下命令：
# Start a new independent line of work on the `otherfeature` branch
# while waiting for review of `myfeature`:
$ git checkout -b otherfeature JIRI_HEAD
# OR
# Start a derivative line of work while waiting for review:
$ git checkout -b otherfeature
当您想要更新 myfeature 分支时，一直都在处理
“独立”otherfeature 分支上的工作行：
# Commit any present dirty work, then, switch to "myfeature":
$ git checkout myfeature
# Make any relevant edits to the code, then:
$ git commit --amend
# Now upload the new patchset to Gerrit:
$ jiri upload
# OR
$ git push origin HEAD:refs/for/main
您因为收到一些评价而想更新 myfeature 分支时
而且您使用的是“导数”工作行：
# Now you get a review comment that needs a change in "myfeature"
# Commit your present work, if you aren't finished, maybe use a work-in-progress change:
$ git commit -a -m "work in progress"
# Start a rebase operation, so you can edit your first change:
$ git rebase -i JIRI_HEAD
# Replace "pick" with "edit" on the change you need to update and save and close the file
# Make the relevant code changes, then:
$ git add . && git rebase --continue
# You may need to make additional "rebase" steps if your edits need integration
# with later commits For each case, look at "git status" to see what files are
# in conflict, and make the relevant adjustments. The rebase is complete when
# git reports "Successfully rebased and updated ...." If you made a "work in
# progress" change and want to unwind that commit:
$ git reset HEAD
# Now you can upload your modified changes to Gerrit:
$ jiri upload
# OR
$ git push origin HEAD:refs/for/main
当您看到“合并冲突”时因为你无法在 Gerrit 中完全
已与 main 分支集成：
# Checkout the branch for the change you need to update (e.g. "myfeature"):
$ git checkout myfeature
# Update your git repository:
$ git fetch
# Update your branch:
$ git rebase origin/main
# Fixup and continue the rebase as necessary, until you see "Successfully rebased ..."
# Then upload your newly updated code:
$ jiri upload
# OR
$ git push origin HEAD:refs/for/main
如果您已工作超过一天，并且需要“同步您的 代码”（您通常希望每天至少执行此操作一次）：
# Commit any in-progress work, then
# Checkout the stable upstream you last sync'd
$ git checkout JIRI_HEAD
# Update your local repository (this will include updates for prebuilts, third
# party repositories, and so on):
$ jiri update -gc
# Now to switch back to, and update your working branch (e.g. "myfeature"):
$ git checkout myfeature
# Updating "myfeature" with the latest stable code:
$ git rebase JIRI_HEAD
# Perform fixups and "git rebase --continue" until you get to "Successfully rebased ..."
请参阅下文，详细了解工作流程的各个部分。 如需详细了解常规 Git 工作流，请参阅 gitworkflows(7)。 如需详细了解有关 Git 的一般信息，请访问 git-scm.com/doc。
重基
同时更新所有项目，并在 JIRI_HEAD 上为您的工作分支执行 rebase 操作：
$ jiri update -gc -rebase-untracked
$ git checkout <my_branch>
$ git rebase JIRI_HEAD
git rebase 到 JIRI_HEAD 应该在每个代码库中完成，
持续的工作。您未处理过的代码库不需要它。
上传更改的新补丁集（快照）
您需要上传一个补丁集，
Gerrit 提交审核请求，
其他。我们使用 jiri upload 执行此操作。
Gerrit 会在变更说明中使用自动生成的元数据标记
确定将补丁上传到哪个 Gerrit 审核会话
身份：Change-Id: I681125d950205fa7654e4a8ac0b3fee7985f5a4f
这与 Git 提交的 SHA 哈希不同，可以被视为稳定 审核期间会发生的所有变化。使用相同的 特定评价的 Change-Id（如果您是 压缩多个 提交）。
如果您已经进行了更改并希望上传新的补丁集，那么（假设
这是您的分支中的最新更改；使用 git log 查找）
例如：
$ git commit -a --amend
# -a for all uncommitted files, --amend to amend latest commit
$ jiri upload
解决合并冲突
尝试 rebase：
$ git fetch origin && git rebase origin/main
# Resolve conflicts as needed...
$ jiri upload
不过，请阅读以下内容，了解 git rebase 如何与 jiri
update 产生负面交互。
密室
您可以保留所有未提交的更改，并在稍后重新应用。 当您刚开始使用 Git 时，这通常非常有用。
$ git stash # uncommitted changes will go away
# do stuff
$ git stash pop # uncommitted changes will come back
问：我经常使用 fx 和 jiri。它们有何关联？
答：它们不相关。
jiri 是封装容器
支持同步管理多个 Git 代码库的 Git
（Fuchsia 代码库由许多 Git 代码库组成）以及
同步一组预构建的工件，例如在 Google Cloud 控制台中找到的
//prebuilt。
fx是
一种便捷封装容器，包含 Fuchsia 树中内置的许多工具，
需要完成许多日常工作流任务，例如构建、运行测试、
日志、连接到设备上的 shell 以及许多其他操作。
问：从 git rebase 到 origin/main 是否会破坏代码库的 jiri 更新（即同步）视图？
答：是，除非 jiri 配置为将基于基础的代码库/Petal 同步到 HEAD
而不是全球集成版本如果您使用
当前/新的默认引导加载程序设置，用于跟踪所有
repos ；但如果您过去设置了检出分支，或者使用了 fx
set-petal X，则可能会出现此情况。
在花瓣 X 上工作（达成 fx set-petal X）时，jiri update会
将 repo X 中的本地分支 rebase 到 origin/main 的 HEAD。但其他
花瓣将同步到可能落后 HEAD 的特定修订版本
其源/主。
Fuchsia 的持续集成系统（特别是 Rollers）进行了新的修订版本
只有测试新修订版本
不会破坏其他花瓣。“jiri update”会始终让其他花瓣同步
这些已成功测试的修订版本但如果使用 git rebase 到源/main，
可能会将代码库推进到测试修订版本之外，
来引入破坏性更改结果可能是
特定花瓣，但其他花瓣不宜（例如，正确制作石榴石，但不适合
制造黄宝石）。
如果您希望 Jiri 遵循特定的承诺，请下载其
jiri.update 文件并将其馈送给 jiri update。
问：如果我需要跨 Git 代码库执行原子提交，该怎么办？
答：不行，抱歉。请尽量合理安排您的更改，确保这些更改不会造成每项更改 （例如，拍一下柔和的花瓣， 过渡）。但有时 必然会破坏东西旨在最大限度地缩短中断时长 （即硬转换）。
示例场景：我在 stem 中定义了一个接口，该接口是在 另一片花瓣。如果我改了界面，肯定会损坏其他花瓣吗？
是。但你可以“照顾孩子”以便最大程度减少损坏范围 关于保姆的注意事项是，其他人也可能在看护婴儿车祸。 还可能导致孩子照看时间比预期要长
或者，您也可以执行以下操作：
- 在
lower中引入作为原始接口的副本 界面。 - 等待
lower-roller进入upper，或者通过更新方法使自己掷骰子 文件upper/manifest。 - 将
upper更改为使用可维护旧界面的新克隆接口 合同。 - 更改
lower，以便将原始接口的协定修改为 所需的新表单 - 等待
lower-roller，或者自行掷骰子。 - 将
upper更改为使用原始接口名称，现在使用其新的接口名称 合同。根据需要进行更改。 - 删除
lower中的克隆接口。
问：如何基于一组源代码执行并行构建？
假设您想要生成四个 build：
- “预备”x64 产品
- “minimal”x64 产品
- “核心”vim3 产品
- “minimal”vim3 产品
首先，必须构建 Zircon，因为 Zircon 构建目录 Fuchsia 构建目标。在这一阶段，使用哪个产品/主板 我们只需开始构建 Zircon 即可。
# We start with bringup, because it's small, but it doesn't matter which you start with:
$ fx --dir out.bringup.x64 set bringup.x64
$ fx --dir out/bringup.x64 build
现在您已经构建了 Zircon，可以开始同时构建其他几个构建：
$ fx --dir out/minimal.x64 set minimal.x64
$ fx --dir out/minimal.x64 build > minimal.x64.build.log &
$ fx --dir out/core.vim3 set core.arm64
$ fx --dir out/core.vim3 build > core.vim3.build.log &
$ fx --dir out/minimal.vim3 set minimal.arm64
$ fx --dir out/minimal.vim3 build > minimal.vim3.build.log &
您可以在运行 fx 工具时引用所有这些 build，方法是将
--dir 添加到您的 fx 命令，例如使用 vim3 minimum 运行 fx serve
产品时，您可以使用：
$ fx --dir out/minimal.vim3 serve
您还可以使用 fx use 更改当前的默认 build 目录：
$ fx use out/core.vim3
问：如果我想使用代码库的先前快照进行构建，该怎么办？
答：您需要针对 jiri 快照文件执行 jiri update，它是一个 XML 文件，
捕获 jiri 跟踪的每个代码库的状态。
问：如何获得适用于特定 fuchsia.git 提交的 build？
答：fx sync-from-stem 会执行这项操作。它在后台使用 jiri。不过，
而不是同步 fuchsia.git 和依赖项以匹配当前集成
代码库，则它会查找与当前已检查的集成
out fuchsia.git，并同步集成和依赖项以匹配
fuchsia.git 提交。
也就是说，fuchsia.git 将保持不变 匹配。在 fuchsia.git 中进行 bisect 操作非常有用。
问：更改 API 时/如何进行软转换和硬转换？
请参阅此部分，了解硬性要求 和软转场效果
问：如何更新 FIDL 协议？
答：更新 FIDL 协议的首选方法是使用软 过渡效果。为了让软过渡正常发挥作用，您需要创建一个 同时支持新旧版本协议的中间状态。
请按照以下步骤执行软转场：
修改 Stem 代码库中的 FIDL 定义，以同时支持旧版 和新的协议元素在实施更改之前，请触发全局变量 集成 tryjobs 来验证第 2 步是否成功。
发布 Stem 代码库，或通过等待每日自动 或手动发布代码库
更新所有客户端以使用新的协议元素。
发布所有客户端。
从 Stem 的 FIDL 定义中移除旧协议元素 存储库
发布 Stem 代码库，通常等待系统每天自动 。
问：如何协调多个花瓣的变化？
答：协调多个花瓣（或主干之间）的原子变化 仓库和一个或多个 Petals）都需要执行硬转换。
请按照以下步骤执行硬转换：
准备对所有受影响的代码库进行更改。如果所有这些代码库 都属于平台源代码树：
- 将相关更改上传到 fuchsia-review.googlesource.com。
- 上传其他用于修改全球集成的更改 代码库以引用更改中的 Git 修订版本。执行 “试运行”提交队列中的相应请求。
通知相关团队，说明您执行硬性转换的意图。
将所有更改提交到受影响的代码库中。此步骤将破坏 进行本地集成，但不会破坏全局 集成，因为这些更改尚未发布。
在全局集成代码库中提交一项引用新更改的更改 受影响的代码库的版本这项更改会让新应用 的新版本，并且不应破坏全局 集成。此更改应该能 代码库
问：如何在发生更改时对历史记录执行二分法跟踪？
答：要对历史记录执行二分法操作，请执行以下步骤：
对配置代码库中的历史记录执行二分法，其中包含 可观察对象之前和之后的全局集成的修订历史记录 更改。此 bisect 操作的结果是对配置进行一次更改 其中可能包含一个或多个 代码库或预构建软件包。
如果对配置代码库的更改是 存储库之前和之后对该存储库的历史记录 全球集成的出版物。此 bisect 操作的结果应为 行为发生更改的修订版本
如果对配置代码库的更改是预构建的发布内容 软件包，请切换到生成预构建软件包时所在的源代码树 创建。请参阅存储库的相关文档，了解如何 对该代码库中的更改执行 bis 命令。
如果对配置代码库的更改是 存储库之后，对历史记录进行二分法的操作会变得很复杂， 您可能也进行了相应更改，因此您需要 一起探索他们的历史。建议研究一下 以了解它们一起发布的原因。
问：我可以在不克隆代码库的情况下搜索 Fuchsia 源代码吗？
答：当然可以！基础代码库 提供了一个 Gitiles 界面， 导航。您还可以使用 Google 开源代码搜索工具 在线浏览和搜索 Fuchsia 代码库。