工作流程提示
這一系列提示可協助您提高工作效率 在 Fuchsia 的幫助下。
安裝 Gerrit Monitor
安裝 Gerrit Monitor 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>] 之類的指令，可開啟
或向 GRU 狀態提供授權
問與答
建議你在這裡新增問題 (和答案)！
問：Fchsia 是否有標準的 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
看到「合併衝突」時因為 我們必須執行
與 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 ..."
如要進一步瞭解工作流程的某些部分，請參閱下方說明。 您可以在 gitworkflows(7) 中進一步瞭解一般 Git 工作流程。 如要進一步瞭解 Git 的一般資訊，請造訪 git-scm.com/doc。
重編
同時更新所有專案，並在 JIRI_HEAD 上重新建構工作分支版本：
$ 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 雜湊不同，且可視為穩定 審核期間以及編輯內容使用相同的 指定評論的變更 ID (以 壓縮多個 修訂版本)。
如果您已進行變更，並想要上傳新的修補程式集，則
這是分支版本最新的變更使用 git log 即可得知)
例如：
$ git commit -a --amend
# -a for all uncommitted files, --amend to amend latest commit
$ jiri upload
解決合併衝突
嘗試重新計算：
$ 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 存放區
(Fchsia 程式碼集由許多 Git 存放區組成)，
同步處理一組預先建構的構件，例如
//prebuilt。
fx是
包含在 Fuchsia 樹中的許多工具周圍，
處理許多日常工作流程任務，例如建構、執行測試
記錄、連線至裝置上的殼層，以及其他許多作業。
問：Git 重新基底至來源/主要是否會影響我對存放區的吉里更新 (即同步處理) 檢視畫面？
答：可以，除非 jiri 設定為將重新式存放區/Petet 與 HEAD 同步
而不是全域整合版本如果您使用的
現有/新預設啟動設定，可用於追蹤以下項目的全域整合
存放區，但如果您使用了過去或使用了 fx
set-petal X 結帳功能，則可能發生這種情況。
在 petal X 工作 (配合 fx set-petal X) 工作時，jiri update 會
將存放區 X 中的本機分支版本重新放入 origin/main 的 HEAD。其他
花瓣存放區將同步到特定修訂版本
這些內容的來源/主
Fuchsia 的持續整合系統 (尤其是滾動式) 執行了新的修訂版本
因此在測試過新的修訂版本後，才能向其他花瓣
我們不能破壞其他花瓣jiri update 一律會保持其他花瓣
這些經過成功測試的修訂版本但為了
地形可推進到受測試修訂版本外的存放區，
來導入破壞性變更您或許能針對
但不適用於其他花瓣 (例如正確地培養紅榴色，但不含
才能打造出頂端
如果您希望 jiri 接受特定修訂版本，請下載該修訂版本
jiri.update 檔案並動態饋給至 jiri update。
問：如果需要跨 Git 存放區建立不可分割的修訂版本，該怎麼辦？
答：抱歉，請安排變更，以免造成每個問題 轉場時請花瓣 (例如，輕快 轉換)。但有時候 你確實會破壞某些要素盡可能減少破壞時間長度 (例如強制轉換)。
範例情境：我有一個在 stem 中定義的介面，且實作在 再來一塊花。變更介面後，是否不小心破壞其他花瓣？
可以。但你可以「寶貝」以盡量減少中斷範圍 保姆的要注意的是，其他人可能可能只是因為系統受傷， 導致您久坐的時間可能會超出您的預期。
或者，您「可以」執行以下動作：
- 在
lower中推出做為原始版本副本的新版介面 存取 API - 等待
lower-roller遷移至upper，或是自行更新upper/manifest檔案。 - 變更
upper，以使用維護舊副本的新介面 合約。 - 變更
lower，以修改原始介面的合約： 所需的新表單 - 請等待
lower-roller，或自行滾動。 - 將
upper變更為使用原始介面名稱，現在改用新的介面 合約。並視需要修改。 - 刪除
lower中的複製介面。
問：如何從單一來源組合進行平行建構作業？
假設您要產生四個版本：
- 「啟動」x64 產品
- 「極簡」x64 產品
- 一個「核心」Vim3 的產品
- 「極簡」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 工具時參照這些建構作業，方法是傳遞
--dir 加到 fx 指令，例如：以使用 Vim3 最低版本執行 fx serve
應使用：
$ fx --dir out/minimal.vim3 serve
您也可以使用 fx use 變更目前預設的建構目錄：
$ fx use out/core.vim3
問：如果我想在各個存放區中的前一個快照進行建構，該怎麼做？
答：您需要 jiri update 對 jiri 快照檔案，也就是一個會
擷取 jiri 追蹤的每個存放區狀態。
問：如何取得適用於特定 Fuchsia.git 修訂版本的建構？
答：fx sync-from-stem 會執行上述操作。實際上會使用 jiri。不過
而不是同步處理 fuchsia.git 和依附元件，以配合目前的整合項目
存放區，而是找出與目前檢查的項目相符的整合修訂版本
out fuchsia.git，並同步處理整合項目和依附元件，藉此達成該要求
fuchsia.git 修訂版本。
換句話說，fuchsia.git 不會有任何改變，其他一切都會同步到 比對。適合用來在 fuchsia.git 內快速變化。
問：何時/如何在變更 API 時進行軟性轉換？
如要瞭解硬體細節，請參閱本節 和柔和轉場效果
問：如何更新 FIDL 通訊協定？
答：如要更新 FIDL 通訊協定，建議您使用 soft 轉換。為了讓柔性轉換作業順利進行，您必須建立 同時支援舊版和新版通訊協定的中繼狀態。
請按照下列步驟執行軟轉換：
請在 Stem 存放區中修改 FIDL 定義，以支援舊版 以及新的通訊協定元素在做出變更之前，先觸發全域的 整合，以驗證步驟 2 是否成功。
發布 Stem 存放區，等待每日自動啟動 或是手動發布存放區
更新所有用戶端以使用新的通訊協定元素。
發布所有用戶端。
從 Stem 的 FIDL 定義中移除舊的通訊協定元素 Cloud Storage 也提供目錄同步處理功能
發布 Stem 存放區，通常是等待每日自動 出版品
問：如何協調多個花瓣的變遷？
答：讓多個花瓣 (或在 Stem 之間) 協調原子變換 存放區和一或多個花瓣粉) 需要執行硬轉換。
請按照下列步驟執行強制轉換：
準備變更所有受影響的存放區。如果這些存放區 是平台來源樹狀結構的一部分：
- 將相關變更上傳至 fuchsia-review.googlesource.com。
- 上傳另一份修改全域整合的變更 來參照變更中的 Git 修訂版本。執行 「模擬測試」這個 Gerrit 變更的修訂佇列。
通知團隊您打算執行強制轉換。
將所有變更放入受影響存放區。這個步驟將會中斷 並整合這些存放區中的本機整合功能，但不會破壞全域 這些變更尚未發布。
在參照新版本的全域整合存放區中推送變更 受影響存放區的版本這項變更就會發布新的 所有受影響存放區的版本，而且不應讓全域版本無法正常運作 擷取及準備資料、針對特定領域進行預先訓練 調整指示、離線評估和整合這項變更應該會取消受影響的本機整合作業 與存放區
問：如果發生變化，我該如何研究歷史紀錄？
答：若要累積記錄，請執行下列步驟：
將含有 可觀測資料的前後全球整合修訂版本記錄 變更。這個帳單的結果為單一設定變更 存放區，假設這些存放區包含 或預先建構的套件
如果設定存放區的變更是發布為單一 並精細調整存放區的歷史記錄 全球整合的出版品這種生物的結果應該是 行為改變的修訂版本
如果設定存放區的變更是預先建構的發布項目 套件，切換至預先建構套件的來源樹狀結構 已建立。如要瞭解如何執行操作，請參閱該存放區的說明文件 存放區中概略的變更
如果設定存放區的變更是由多個 以及整理記錄變得複雜，因為 這些存放區可能有異動，您必須 走進他們的歷史建議您研究 瞭解為什麼會同時發布存放區。
問：我可以在不複製存放區的情況下搜尋 Fuchsia 原始碼嗎？
答：當然可以！基本存放區 提供了 Gitiles UI 給 導覽。您也可以使用 開放原始碼工具 ，在線上瀏覽及搜尋 Fuchsia 程式碼集。