提交與拉取請求慣例
將 PR 標題與初始主體視為壓縮合併 (squash-and-merge) 後將會套用的確切提交訊息。
提交訊息
- 首先閱讀儲存庫的指示。使用儲存庫本地的
commit-scope技能來推導範圍。如果該技能不可用，則使用明確的儲存庫規則，若無所獲則省略範圍，切勿自行發明。 - 遵循 Conventional Commits 格式：
<類型>[可選範圍][!]: <描述>。 - 目標為 50 個字元，並描述變更後的行為結果。不要為了達到此目標而刪除儲存庫要求的範圍；當範圍使得描述太長時，保持其餘描述盡可能簡潔。
- 使用空白行分隔主旨、主體與頁尾。
- 對於獨立提交，主體行請在 72 個字元處換行。說明為何需要此變更、如何解決問題，以及相關的實質副作用。
- 將現有的工單金鑰或連結放在頁尾，而非主旨中：
Issue: PROJECT-123。若存在工單，則遵循儲存庫特定的頁尾格式。若無工單，則省略頁尾，而非虛構Issue: N/A。 - 添加適用的 Conventional Commits 頁尾，以及協作者的
Co-authored-by: Name <email>尾綴。 - 根據受影響的表面選擇類型，而非根據變更是否修復了缺陷。
- 使用
ci表示 CI、工作流程與自動化變更，包括對該自動化的修復。 - 使用
fix表示產品或執行階段的錯誤，以及對外部公開 API 邊界進行的非功能變更。 - 使用
feat表示功能，build表示建置或依賴項，chore表示非產品工具或設定，docs表示僅文件變更，style表示非語義的編輯，refactor表示內部重構，test表示測試，perf表示效能。 - 使用
!或BREAKING CHANGE頁尾標記破壞性變更，但仍保持類型準確。 - 確保每個未壓縮的開發提交都保持一致且符合慣例。
fix(storage): preserve collated indexes
Normalize server-expanded collations before comparing index definitions.
Issue: PROJECT-123
拉取請求
- 將標題設定為預期的壓縮提交主旨，必須完全相同。
- 將初始主體設定為預期的壓縮提交主體與頁尾，必須完全相同。排除僅與 PR 相關的前言、檢查清單與實作日誌。
- 請不要手動為 PR 主體換行；GitHub 會處理顯示換行。
- 保持永久歷史簡潔：記錄動機、實質行為與副作用。
- 將實驗、替代方案、大量驗證與實作時間線放在後續留言中。
- 發表一則後續留言，內容包含變更的行數，並至少分為生產程式碼、測試與其他檔案，以便審查者在閱讀變更前了解其權重所在；如何計算與呈現由您決定，並在差異有重大變更時重新整理。
- 隨著實作演進，更新標題與初始主體。
- 在開啟、更新或合併之前，將
標題 + 空白行 + 主體作為一條提交訊息來閱讀，並修正任何不一致之處。