前言¶
在 DeepSeek Harness（DSH）裏讓 agent 幫忙改代碼時，常見情況是：每次開分支、寫 commit message、提 PR 或打 tag，都要臨時口述一套流程，agent 也容易按通用習慣而不是團隊約定行事。託管平臺、CI 各自不同，但 Git 本地的分支模型、Conventional Commits、評審順序、歷史改寫與誤操作恢復，往往可以事先寫進文檔並讓 agent 按同一套紀律執行。
下面介紹社區插件 dsh-git-workflow（npm 包名 @jojonadam/dsh-git-workflow，倉庫 JOJO-Adam/dsh-git-workflow）。裝好之後，agent 在開分支、寫提交、提 PR、發版本之前會先按你們自己的規矩走，而不是每次現編一套。插件歸類爲「工作流」，維護者爲 JOJO-Adam（作者署名 JOJO & Adam）；當前 package 版本爲 0.1.0，許可證 MIT。DSH 生態採用「一切皆插件」思路，目錄頁在 skillhub.cn，與 DeepSeek / 幻方無官方從屬關係。
這是什麼¶
dsh-git-workflow 的定位是：面向 DeepSeek Harness 的 Git workflow studio——把分支模型、提交規範、PR 評審、歷史 surgery、災難恢復、發佈版本等能力，以約 7 個 skill（README 與 package 描述中亦稱「六本手冊」）的形式交給 agent 調用。它只覆蓋 Git 本身，不替你們選託管平臺，也不碰 CI 配置的具體實現。
核心功能¶
以下能力均來自插件 README 與 package 描述，安裝後 agent 可在相關場景下引用對應技能。
- 定流程：版本基線、分支模型決策樹、協作流程、提交/評審/發佈紀律，一次說清。
- 統一提交：Conventional Commits 的 type/scope 約定，含破壞性變更怎麼寫。
- 評 PR：PR 描述模板、按缺陷密度排序的評審順序、合併前檢查清單。
- 改歷史：交互式 rebase、squash 與 fixup 的取捨、cherry-pick 區間，以及「已 push 就別動」的紅線。
- 救火：reflog 找回丟失的提交、恢復誤刪分支、reset 錯了怎麼辦。
- 發版本：按實際行爲變化定 semver，打 tag 與發佈流程。
邊界：破壞性操作提供的是判斷與命令清單，執行前由你確認，插件不會自動跑危險命令。
安裝與啓用¶
插件要求 DSH >=0.2.0-rc.2、Node >=20，並聲明 peer 依賴 @deepseek-ai/cordis ~4.0.5。安裝前建議閱讀倉庫源碼與 LICENSE，並知曉插件以當前 dsh 進程權限運行。
Web 版與桌面版使用同一包名，通過 profile 區分：
# Web 版
dsh plugin --profile web add @jojonadam/dsh-git-workflow
# 桌面版
dsh plugin --profile desktop add @jojonadam/dsh-git-workflow
典型用法¶
怎麼觸發：直接用自然語言即可，也可以顯式點名技能。README 給出的示例如下：
- 「這次改動該升 major 還是 minor」
- 「幫我把這三個提交壓成一個」
- 「我把分支刪了怎麼找回」
經過上面的步驟，agent 會在動手前對齊你們文檔裏的分支與提交紀律，而不是臨時拼湊一套 Git 命令。
適用場景與注意¶
適合誰：需要在 DSH 對話裏穩定複用 Git 紀律的團隊或個人——尤其是已經採用或打算採用 Conventional Commits、固定 PR 評審順序、semver 發版，但又不想每次手動粘貼 wiki 的場景。
注意：
- 不替代 GitHub/GitLab 等平臺側的 PR 按鈕與保護分支策略；只約束 agent 如何建議、如何列出命令。
- 歷史改寫、reset、force 等操作務必人工確認後再執行。
- 社區目錄與 GitHub 星標（截至資料抓取時爲 0）僅作發現與溯源，不代表官方背書。
結尾¶
dsh-git-workflow 把 Git 工作流從「每次口頭交代」變成裝插件即可調用的技能集：流程、提交、評審、改歷史、恢復、發版各有一塊。若要查看簡介與安裝入口，可打開 SkillHub 目錄頁；細節與 issue 見 GitHub 倉庫。
