工作流程提示
以下技巧列表可帮助您提高使用 Fuchsia 的工作效率。
安装 Gerrit Monitor
安装 Gerrit Monitor Chrome 扩展程序，以在 Chrome 工具栏中添加需要您注意的 Gerrit 更改列表。
优化您的 Gerrit 设置
查看 Gerrit 设置并根据需要进行调整。例如，您可能需要启用“在推送时发布评论”，该功能会在有新的补丁集发布时自动发送草稿评论，您无需通过网页界面手动执行此操作。
在 Git 中启用三向差异比较
默认情况下，Git 在显示冲突时使用双向差异比较。它不会显示冲突之前的原始文本，因此难以解决一些冲突。
您可以通过启用三向差异比较来将 Git 配置为显示原始文本：
git config --global merge.conflictstyle diff3
启用特定于 Fuchsia 的 Git 命令
将 $FUCHSIA_DIR/scripts/git 添加到 PATH 中，以便能够使用特定于 fuchsia 的 Git 命令（例如 git fuchsia-review [<commit ref>]），从而在 Gerrit 中打开当前或给定的提交内容。
问题和解答
欢迎您在此处添加您自己的问题（和答案）！
问： Fuchsia 是否有标准 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 更改！
假设您想在等待对 myfeature 分支上的工作进行审核时在 otherfeature 分支上启动新工作：
# 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-scm.com/doc，详细了解有关 Git 的一般信息。
基础重构
同时更新所有项目，并在 JIRI_HEAD 上对工作分支执行 rebase 操作：
$ jiri update -gc -rebase-untracked
$ git checkout <my_branch>
$ git rebase JIRI_HEAD
对 JIRI_HEAD 的 git rebase 操作应在持续工作的每个代码库中完成。您未接触过的代码库无需使用该模块。
上传更改的新补丁集（快照）
您需要上传设为 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 代码库（Fucchsia 代码库由许多 Git 代码库组成），以及同步一组预构建的工件，例如在 //prebuilt 中找到的工件。fx 是一个便捷的封装容器，用于封装 Fuchsia 树中内置的许多工具，有助于处理许多日常工作流任务，如构建、运行测试、使用日志、连接到设备上的 shell 以及许多其他操作。
问：Git rebase 到 origin/main 后会干扰代码库的 jiri 更新（即同步）视图吗？
答：是，除非 jiri 配置为将基于后的代码库/petal 同步到 HEAD，而不是全局集成版本。如果您使用当前/新的默认引导加载程序设置（用于跟踪所有代码库的全局集成），则不会出现这种情况。但如果您过去设置过结账流程或使用过 fx
set-petal X，就可能会出现这种情况。
在处理 Peal X 时（通过 fx set-petal X 完成），jiri update 会将代码库 X 中的本地分支 rebase 到源/主程序的 HEAD 上。但是，其他花瓣的代码库将同步到可能落后于其源/主 HEAD 的特定修订版本。
Fuchsia 的持续集成系统（尤其是滚轮）只有在测试新修订版本不会破坏其他花瓣后，才能将新修订版本提供给其他花瓣。jiri update 始终会将其他花瓣同步到这些成功测试的修订版本。但是，Git rebase 到花瓣的源/主代码库可能会超出经过测试的修订版本，从而有可能引入破坏性更改。结果可能是，您可以针对某些花瓣进行构建，但无法为其他花瓣进行构建（例如，正确构建了石榴石，但无法构建黄晶）。
如果您希望 jiri 遵循特定的提交内容，请下载其 jiri.update 文件并将其提供给 jiri update。
问：如果我需要跨 Git 代码库进行原子提交，该怎么办？
答：不能，抱歉。尝试安排您的更改，使其在过渡期间不会破坏每个花瓣（即进行“软过渡”）。但有时，您一定会造成破坏；应尽量缩短中断持续时间（即硬转换）。
示例场景：我在 Stem 中定义了一个接口，然后在另一个花瓣中实现了该接口。如果我更换界面，是不是注定要破坏其他花瓣？
是的。但您可以“安保”滚轮，以便将损坏范围降到最低。 有关保姆的注意事项是，其他人可能也在照顾受损的婴儿，而您最后照顾保姆的时间可能会超出您的预期。
或者，您也可以执行以下操作：
- 在
lower中引入一个新接口，它是原始接口的副本。 - 等待
lower-roller滚动到upper，或者通过更新文件upper/manifest自行滚动。 - 更改
upper以使用保留旧合约的新克隆接口。 - 更改
lower，以将原始接口的协定修改为所需的新形式。 - 您可以等待
lower-roller，也可以自己掷骰子。 - 更改了
upper以使用原来的接口名称，现在有了新的协定。根据需要进行更改。 - 删除
lower中的克隆接口。
问：如何从一组源进行并行构建？
假设您要生成四个 build：
- x64 的“bringup”产品
- x64 的“最小”产品
- vim3 的“核心”产品
- vim3 的“minimal”产品
首先，必须构建 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，可以开始同时构建多个其他 build：
$ 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 最低产品运行 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。但是，该 API 不会同步 fuchsia.git 和依赖项以匹配当前的集成代码库，而是会查找与当前已检出的 fuchsia.git 匹配的集成提交，并同步集成和依赖项以匹配该 fuchsia.git 提交。
换句话说，fuchsia.git 将保持不变，所有其他内容都会同步以匹配。这对于在 fuchsia.git 中进行二分法非常有用。
问：如果我是在 Mac 上进行构建，如何才能避免收到“传入网络连接”通知的垃圾内容？
答：您将需要运行 fx setup-macos，它会通过 MacOS 应用防火墙注册所有相关的 Fuchsia 工具。
问：更改 API 时，何时/如何进行软转换与硬转换？
如需了解硬转换和软转换，请参阅此部分。
问：如何更新 FIDL 协议？
答：更新 FIDL 协议的首选方法是使用软转换。为使软转换起作用，您需要创建同时支持旧版和新版协议的中间状态。
请按照以下步骤执行软转换：
修改 Stem 代码库中的 FIDL 定义，同时支持新旧协议元素。在发布更改之前，请触发全局集成 tryjobs，以验证第 2 步是否成功。
通过等待每日自动发布或手动发布 Stem 代码库来发布 Stem 代码库。
更新所有客户端以使用新的协议元素。
发布所有客户端。
从 Stem 代码库的 FIDL 定义中移除旧协议元素。
发布 Stem 代码库，通常等待每日自动发布。
问：如何协调多个花瓣的更改？
答：协调多个花瓣（或在 Stem 代码库和一个或多个花瓣之间）的原子更改需要执行硬转换。
请按照以下步骤执行硬转换：
准备对所有受影响的代码库进行更改。如果所有这些代码库都是平台源代码树的一部分：
- 将相关更改上传到 fuchsia-review.googlesource.com。
- 上传另一个更改，用于修改全局集成代码库，以引用您的更改中的 Git 修订版本。对此 Gerrit 更改执行提交队列的“试运行”。
告知团队您打算执行硬性转换。
将所有更改转移到受影响的代码库中。此步骤将破坏这些代码库中的本地集成，但不会破坏全局集成，因为更改尚未发布。
在全局集成代码库中提交更改，这些更改会引用受影响代码库的新版本。此更改将发布所有受影响代码库的新版本，并且应该不会破坏全局集成。此更改应该会破坏受影响代码库中的本地集成。
问：如何对历史记录进行二分化，以便在情况发生变化时进行跟踪？
答：如需对历史记录进行二元分割，请执行以下步骤：
对配置代码库中的历史记录（包含可观察更改之前和之后全局集成的修订历史记录）中的历史记录二分。此 bisect 的结果将是对配置代码库的单个更改，可能包括发布一个或多个代码库或预构建软件包。
如果对配置代码库的更改是单个代码库的发布，请在发布全局集成之前和之后对该代码库的历史记录进行二元分割。此二分法的结果应该是行为发生更改的修订版本。
如果对配置代码库的更改是预构建软件包的发布内容，请切换到创建预构建软件包的源代码树。如需了解如何对该代码库中的更改进行二分化，请参阅该代码库的文档。
如果对配置代码库的更改是多个代码库的发布，则二分历史记录会变得很复杂，因为这两个代码库可能一致地发生了更改，您需要同时遍历其历史记录。请考虑研究这些代码库的历史，以了解它们一起发布的原因。
问：我可以在不克隆代码库的情况下搜索 Fuchsia 源代码吗？
答：当然可以！基础代码库提供用于导航的 Gitiles 界面。您还可以使用 Google 开源代码搜索工具在线浏览和搜索 Fuchsia 代码库。