由於無法一次將變更一次提交至多個 Git 存放區，因此開發人員必須謹慎協調會影響多個花瓣的變更內容。
舉例來說，如果 Fuchsia 樹狀結構中的 API 或 ABI 變更會影響 Flutter 或 Go 中的呼叫端，就必須進行軟轉換 (建議採用) 或硬式編碼。
請注意，某些花瓣可能不在一般的 Fuchsia 結帳流程中。 舉例來說，雖然 Go 執行階段是 third_party/go 的一部分，但其他 Fuchsia SDK 取用者可以透過其他位置開發 (例如在 GitHub 上開發 Flutter Engine)。
術語
D- 用於 Fuchsia 樹狀結構中的專案。P- 另一個在 Fuchsia 樹狀結構中使用，直接依附於D的專案。舉例來說，D可能是 Fuchsia，P可能是 Topaz 或 Experiences。- 整合 - 內部整合存放區。
軟轉換
如需進行跨多個專案的變更，建議您使用軟轉換。在柔性轉換中，您變更了 D，使介面同時支援新舊用戶端。舉例來說，如果您要取代函式，可以加入新版本並將舊函式轉換成新函式的包裝函式。
請按照下列步驟完成柔性轉換：
- 在
D中導入會導入新介面的變更，且不會破壞P使用的舊介面。 - 等待
D的新修訂版本發布至整合存放區。 - 如要使用新版介面，請遷移
P。 - 等待
P的新修訂版本發布至整合存放區。 - 在
D中進行清除變更，移除舊介面。
一般而言，可以藉由軟轉換來更新 FIDL 通訊協定。
硬轉換
對某些變更來說，建立軟轉換並不容易，甚至無法執行。您可以針對這類變更，進行「硬轉換」。在強制轉換中，您會對 D 進行破壞性變更，並手動更新 P。
請注意，為防止意外偽裝資訊清單內容，Gerrit 的設定不會自動重新依據編輯資訊清單檔案的變更。您必須在合併之前手動重新基準，才能確保提交的內容採用精準快轉設定。
比起進行軟轉換，進行硬性轉換比進行軟轉換更為壓力，因為您的變更會在步驟 1 和 2 之間，防止 D 的其他變更成為相依專案。
只有 Google 開發人員才能進行硬式編碼。如需操作說明，請參閱內部說明文件。