Daniel-DB-hub/developer-portfolio

遵循 Git 工作流程

核心規則

production 是唯一的長期分支。永遠不要直接在上面工作。

在執行任何 Git 寫入操作之前：

1. 執行 git status --short --branch。
2. 確認沒有預期外的檔案或變更。
3. 擷取遠端資料。
4. 建立或切換到一個短期任務分支。
5. 將分支限制在單一目標內。

分支名稱

使用：

• feat/<scope>
• fix/<scope>
• hotfix/<scope>
• test/<scope>
• docs/<scope>
• refactor/<scope>
• chore/<scope>

使用小寫的 kebab-case。永遠不要使用 main、dev-production、changes、update 或類似的模糊名稱。

提交之前

1. 審查 git diff 和 git diff --staged。
2. 移除不相關的檔案。
3. 如果出現機密、私人證據、內部 URL、原始 AI 對話記錄、客戶資料或學生資料，請停止。
4. 執行與變更範圍相關的檢查。
5. 使用 Conventional Commit 訊息。
6. 除非明確要求，否則不要添加 AI 共同作者署名。

推送與 Pull Request

• 永遠不要直接推送到 production。
• 永遠不要強制推送 production。
• 永遠不要繞過鉤子或必要的檢查。
• 永遠不要使用單純的 --force。
• 只有在明確批准後，才能在任務分支上使用 --force-with-lease。
• 每個 production 變更都必須經過 Pull Request。
• 遵循 .github/pull_request_template.md。

合併邊界

除非 Randi 在當前對話中明確批准合併特定的 Pull Request，否則 Claude 必須在合併前停止。

僅使用 squash merge。合併後刪除任務分支。

完成報告

報告：

• 分支
• 提交
• 執行的檢查與結果
• Pull Request 狀態
• 機密性審查
• 剩餘風險
• 是否需要合併批准

完整政策

閱讀並遵循：

• docs/governance/git-workflow.md
• docs/governance/github-configuration.md