提取要求 — MRTK2

必要條件

如果您之前尚未參與 Microsoft 專案,系統可能會要求您簽署 參與授權合約。 PR 中的批註可讓您知道您是否這麼做。

重要

如果您是 Microsoft 員工,且不是 GitHub 上的 Microsoft 組織成員,請在開始提取要求之前流覽 Microsoft 的開放原始碼 ,在 corpnet 上連結您的 Microsoft 和 GitHub 帳戶。 您需要事先執行一些程式工作。

建立提取要求

當您準備好提交提取要求時,請建立以主要分支為目標的提取要求。 如需發行穩定期間的錯誤修正,請尋找最新的 prerelease/* 分支。 新功能應該一律進入 main

閱讀指導方針並確保提取要求符合指導方針。

  • 請務必參考 PR 與相關的任何問題/功能要求或工作。
  • 檢查提取要求只包含與 PR 相關的檔案/變更。
  • 檢查檔是最新的,並已包含。 檢查所有公用欄位都有批註。
  • 如果新增功能,請檢查是否已包含測試來驗證功能 (請參閱 UnitTests) 。
  • 如果修正錯誤,請撰寫測試來驗證錯誤修正。

專案維護人員將會檢閱您的變更。 我們的目標是在三個工作天內檢閱所有變更。 請處理任何評論意見、推送至您的主題分支,並張貼批註,讓我們知道有新內容可供檢閱。

注意

所有提交至專案的 PR 也會根據 MRTK 編碼標準指南進行審查,因此請先檢閱這些程式,再提交 PR 以確保程式順暢。

提取要求指導方針

這些指導方針是以 Google 的工程實務為基礎。

讓提取要求保持小

較小型的 PR 會更快速且徹底地檢閱、較不可能會引入 Bug、更容易復原,以及更容易合併。

提取要求應該小到足以讓工程師在 30 分鐘內檢閱。 嘗試進行最低限度的變更,只處理一件事。 如果您必須建立大型 PR,請將它分割成數個進入本機分支的 PR,或 MRTK 的功能分支。 請避免 (新增資產,例如 fbx、obj 檔案) ,而是想要重複使用現有的資產。

測試應該新增到與修正/功能相同的 PR 中,但除了緊急狀況之外

測試是確保變更不會回歸現有程式碼的最佳方式,但是提交提取要求時也很容易忘記測試。 要求他們使用您的 PR 是確保撰寫測試的絕佳方式。

每個功能和 Bug 修正都應該有與其相關聯的測試。 如果您沒有撰寫測試的專業知識或時間,請建立問題以撰寫測試,並以 [ 考慮目前反復專案]標籤標示它們。

應該在與修正/功能相同的提取要求中新增檔

大部分開發人員在瞭解如何使用功能時先查看檔,而不是程式碼。 確保檔是最新的,可讓使用者更輕鬆地取用及依賴 MRTK。 檔應一律與相關的提取配套,以確保專案保持最新且一致。

請確定每個公用欄位、方法、屬性都有 三個斜線摘要批註 ,因此我們的 docfx 網站可以產生欄位/方法的描述。 如有需要,請在 [檔] 資料夾中更新 Markdown 檔案。

提取要求描述應該清楚且完全描述變更

清楚且完整的提取要求描述,可確保檢閱者瞭解他們正在檢閱的內容。

如果新增包含 UX 的功能,請新增您要變更之功能的影像/gif。 以下是良好的範例。 另一個建議是擁有 Before 和 After 的 gif, 例如在此提取要求中。 我們建議從螢幕擷取產生 gif 的工具是 ScreenToGif