Updated workflow

Upgrade to python3
2026-04-13 13:34:06 +08:00 · 2026-04-13 13:28:35 +08:00
25 changed files with 102 additions and 702 deletions
@@ -11,80 +11,118 @@ jobs:
    runs-on: linux
    
    steps:
-      # 第一步：更新主工作树
-      - name: Update main worktree
+      # 第一步: 设置主工作树和虚拟环境
+      - name: Setup main worktree and virtual environment
        run: |
-          echo "=== Updating main worktree ==="
+          echo "=== Setting up main worktree ==="
+          
+          # 如果主目录不存在，克隆仓库
+          if [ ! -d "/home/ly0kos/work/test_env" ]; then
+            echo "Cloning repository to main worktree..."
+            git clone http://localhost:3000/yuysh/Manlink_Doc.git /home/ly0kos/work/test_env
+            cd /home/ly0kos/work/test_env
+            
+            # 创建共享虚拟环境
+            python3 -m venv .venv-shared
+            source .venv-shared/bin/activate
+            pip install --upgrade pip
+            pip install sphinx sphinx-rtd-theme
+            
+            # 记录初始依赖状态
+            if [ -f "requirements.txt" ]; then
+              pip install -r requirements.txt
+              stat -c %Y requirements.txt > .venv-shared/last_update.txt
+            fi
+          else
+            cd /home/ly0kos/work/test_env
+            git fetch --all --prune
+            git checkout master
+            git pull origin master
+          fi
+          
+          echo "✓ Main worktree ready"
+
+      # 第二步: 为PR分支创建工作树
+      - name: Create worktree for PR branch
+        run: |
+          echo "=== Creating worktree for PR branch: ${{ github.head_ref }} ==="
          cd /home/ly0kos/work/test_env
          
-          git fetch --all --prune
-          git checkout master
-          git pull origin master
+          # 清理可能存在的旧工作树
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
+          if [ -d "$WORKTREE_DIR" ]; then
+            echo "Removing existing worktree..."
+            git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true
+            rm -rf "$WORKTREE_DIR" 2>/dev/null || true
+          fi
          
-          echo "✓ Main worktree updated"
+          # 创建新的工作树
+          mkdir -p "/home/ly0kos/work/test_env/worktrees"
+          git fetch origin ${{ github.head_ref }}:${{ github.head_ref }} --force
+          git worktree add "/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}" ${{ github.head_ref }} --force
          
-      # 第二步：复用共享虚拟环境
+          echo "✓ Worktree created at: /home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
+
+      # 第三步: 复用共享虚拟环境并检查依赖更新
      - name: Reuse shared virtual environment
        run: |
-          echo "=== Using shared virtual environment ==="
+          echo "=== Reusing shared virtual environment ==="
          cd /home/ly0kos/work/test_env
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
+          
+          # 使用主工作树的共享虚拟环境
          source .venv-shared/bin/activate
          
-          # 检查主分支的requirements.txt是否有更新
-          if [ -f "requirements.txt" ]; then
-            REQ_MOD_TIME=$(stat -c %Y requirements.txt 2>/dev/null || echo 0)
+          # 检查PR分支的requirements.txt是否有更新
+          if [ -f "$WORKTREE_DIR/requirements.txt" ]; then
+            echo "Checking for dependency updates in PR branch..."
+            REQ_MOD_TIME=$(stat -c %Y "$WORKTREE_DIR/requirements.txt" 2>/dev/null || echo 0)
            VENV_MOD_TIME=$(cat .venv-shared/last_update.txt 2>/dev/null || echo 0)
            
            if [ $REQ_MOD_TIME -gt $VENV_MOD_TIME ]; then
-              echo "Master branch requirements updated, installing new dependencies..."
-              pip install -r requirements.txt --no-cache-dir
+              echo "PR branch requirements updated, installing new dependencies..."
+              pip install -r "$WORKTREE_DIR/requirements.txt"
              echo $REQ_MOD_TIME > .venv-shared/last_update.txt
+              echo "Dependencies updated from PR branch"
+            else
+              echo "No changes in requirements, using existing packages"
            fi
          fi
          
-      # 第三步：从主工作树构建文档
-      - name: Build documentation from master
+          echo "python3: $(python3 --version)"
+          echo "Sphinx: $(sphinx-build --version 2>/dev/null || echo 'Not installed')"
+
+      # 第四步: 在工作树中构建文档
+      - name: Build documentation in worktree
        run: |
-          echo "=== Building production documentation ==="
+          echo "=== Building documentation in worktree ==="
          cd /home/ly0kos/work/test_env
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
          source .venv-shared/bin/activate
          
-          rm -rf build/
-          sphinx-build -b html source build -v -j 4
-          echo "✓ Production build completed"
+          # 构建文档
+          cd "$WORKTREE_DIR"
+          sphinx-build -b html source "$WORKTREE_DIR/build" -v -j 4
          
-      # 第四步：部署到Web服务器
-      - name: Deploy to web server
+          # 复制到预览位置
+          mkdir -p /home/ly0kos/work/test_env/pr-builds/
+          rm -rf /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}
+          cp -r "$WORKTREE_DIR/build" /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}
+          
+          echo "✓ Build completed for PR branch: ${{ github.head_ref }}"
+
+      # 第五步: 验证构建结果
+      - name: Verify build
        run: |
-          echo "=== Deploying to production ==="
-          cd /home/ly0kos/work/test_env
+          echo "Build output for PR ${{ github.head_ref }}:"
+          ls -la /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/ | head -10
      
-          rm -rf /var/www/docs_dev/*
-          cp -r build/* /var/www/docs_dev/
-          
-          echo "✓ Documentation deployed"
-
-      # 第五步：清理PR工作树
-      - name: Cleanup PR worktree
+      # 第六步: 复制至测试目录
+      - name: Copy to dev folder
        run: |
-          echo "=== Cleaning up PR worktree ==="
-          cd /home/ly0kos/work/test_env
-          
-          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
-          if [ -d "$WORKTREE_DIR" ]; then
-            git worktree remove "$WORKTREE_DIR" --force
-            echo "✓ Removed worktree for ${{ github.head_ref }}"
-          fi
-          
-          # 清理预览文件
-          PREVIEW_DIR="/home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}"
-          if [ -d "$PREVIEW_DIR" ]; then
-            rm -rf "$PREVIEW_DIR"
-            echo "✓ Removed preview for ${{ github.head_ref }}"
-          fi
-
-      # 第六步：验证部署
-      - name: Verify deployment
-        run: |
-          echo "Production deployment completed!"
-          ls -la /var/www/docs_dev/ | head -10
+          echo "Now clear dev folder"
+          rm -rf /var/www/docs/*
+          echo "Copy build to dev folder"
+          cp -r /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/* /var/www/docs/
+          echo "✓ Documentation in Product folder now!"
+          echo "Please check http://mkb.local to See Changes"
@@ -11,7 +11,7 @@ jobs:
    runs-on: linux

    steps:
-      # 第一步：设置主工作树和虚拟环境
+      # 第一步: 设置主工作树和虚拟环境
      - name: Setup main worktree and virtual environment
        run: |
          echo "=== Setting up main worktree ==="
@@ -23,7 +23,7 @@ jobs:
            cd /home/ly0kos/work/test_env
            
            # 创建共享虚拟环境
-            python -m venv .venv-shared
+            python3 -m venv .venv-shared
            source .venv-shared/bin/activate
            pip install --upgrade pip
            pip install sphinx sphinx-rtd-theme
@@ -42,7 +42,7 @@ jobs:
          
          echo "✓ Main worktree ready"

-      # 第二步：为PR分支创建工作树
+      # 第二步: 为PR分支创建工作树
      - name: Create worktree for PR branch
        run: |
          echo "=== Creating worktree for PR branch: ${{ github.head_ref }} ==="
@@ -63,7 +63,7 @@ jobs:
          
          echo "✓ Worktree created at: /home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"

-      # 第三步：复用共享虚拟环境并检查依赖更新
+      # 第三步: 复用共享虚拟环境并检查依赖更新
      - name: Reuse shared virtual environment
        run: |
          echo "=== Reusing shared virtual environment ==="
@@ -89,10 +89,10 @@ jobs:
            fi
          fi
          
-          echo "Python: $(python --version)"
+          echo "python3: $(python3 --version)"
          echo "Sphinx: $(sphinx-build --version 2>/dev/null || echo 'Not installed')"

-      # 第四步：在工作树中构建文档
+      # 第四步: 在工作树中构建文档
      - name: Build documentation in worktree
        run: |
          echo "=== Building documentation in worktree ==="
@@ -111,13 +111,13 @@ jobs:
          
          echo "✓ Build completed for PR branch: ${{ github.head_ref }}"

-      # 第五步：验证构建结果
+      # 第五步: 验证构建结果
      - name: Verify build
        run: |
          echo "Build output for PR ${{ github.head_ref }}:"
          ls -la /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/ | head -10
      
-      # 第六步：复制至测试目录
+      # 第六步: 复制至测试目录
      - name: Copy to dev folder
        run: |
          echo "Now clear dev folder"
@@ -126,3 +126,4 @@ jobs:
          cp -r /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/* /var/www/docs_dev/
          echo "✓ Documentation in DEV folder now!"
          echo "Please check http://mkb.local:880 to Verify Changes"
+
@@ -1,97 +1,3 @@
 # MKB

 Manlink Knowledge Base
---
-## About
-此仓库用于储存及生成知识库网页
-
-[点我访问正式版网页](http://mkb.local)
-
-*[若无法访问，尝试直接访问ip](http://172.18.32.40/)*
-
---
-## Getting Started
-
-### 前期准备
-1. 在[这里](http://mkb.local:3000/user/sign_up)注册账号
-2. 通知管理员将账户加入`Manlink_Doc` 仓库
-3. 确保连接`manlink_internal`网络 
-
-### 环境部署
-1. <a href = "http://mkb.local/_static/deploy/deploy.exe"> 点我下载环境 </a>
-2. 解压压缩文件后运行`deploy.bat`，并根据提示输入必要信息(仅限英文字符)
-3. 若批处理正确运行完成，则应在解压目录下生成RUNME.bat
-4. 双击RUNME.bat，应打开`vscode`环境并自动打开仓库目录
-5. 现在您可以对仓库进行`签出`、`提交`等操作
-6. 可能在提交时会提示输入用户名/密码(请输入gitea账户密码)
-
-### VSCode-Git 使用说明
-
-1. 在完成环境部署后，vscode中源代码管理功能应可用，从侧边栏中访问该功能
-   ![VSCode Git](./Readme/img/vscode_git.png)
-2. 想要对知识库页面进行编辑时，需**签出新分支**，参考下图步骤
-
-    ![](./Readme/img/vscode_checkout.png)
-    ![](./Readme/img/vscode_new_branch.png)
-
-> [!CAUTION]
-> 请不要直接对`master`分支进行修改！
->修改前请**签出**分支，修改完成后请发起***合并分支***请求
-
-3. 在进行编辑后点击这里进行推送/发布新分支
-   ![](./Readme/img/vscode_push.png)
-
-> [!NOTE]
-> 
-> 想要更加详细了解Git可以参考[这篇文档](./Readme/git.md)
-
-### 添加/修改内容
-
-1. 本知识库采用`Sphinx`作为解析、生成工具，并*推荐*主要以`Markdown`语言作为文档的原始语言格式,`reStructuredText`语言作为辅助
-2. `source`文件夹即为知识库原始文件夹，通过文件树及`index.rst`进行网页层级管理
-
-> [!IMPORTANT]  
-> 请**不要**修改`source/conf.py`其为`Sphinx`配置文件！如需修改请提交PR至管理员
-
-3. 创建文档时：
-   1. 请将图片放入`_images/`目录下，建议单独创建文件夹以保证目录整洁
-   2. 其他数据，如：实验数据、日志等，请放入`_static/`目录下，同样建议创建文件夹以保证目录整洁
-   3. 对于新创建的文档：
-      1. 如已存在对应目录，则仅需在对应目录下创建文档即可，建议保证文件名具有**通俗易懂**的可读性
-      2. 如不存在目录，则需创建目录及`index.rst`，并更新上级的`index.rst`或`index.md`，具体内容可参考已有文档，如[子目录index.rst](./source/Mars_1KS/DC/PPMU/1.0/index.rst)及[父目录index.rst](./source/Mars_1KS/index.rst)之后新建文档
-   
-> [!Note]
->
-> 对于Markdown语法，可以参考[这篇文档](./Readme/markdown.md)
-
-
-### 测试及合并请求
-
-1. 在您完成编辑后可以对您的分支发起合并请求(Pull Request)，推荐通过网页进行这一操作，其位置如下图：
-   ![PR](./Readme/img/PR.png)
-
-    > [!WARNING]  
-    > 您仅应对您编辑的分支发起合并请求
-
-2. 在创建合并请求界面，需清晰明了的创建标题及合并请求正文，如需合作，也可在指派成员一栏邀请成员进行合作
-
-    ![PR_Create](./Readme/img/PR_Create.png)
-
-3. 创建合并分支后会默认触发自动化部署，如下图所示
-    
-    ![Pr_Action](./Readme/img/Pr_Action.png)
-
-   在正常情况下，自动化部署应顺利完成(理论运行时间<5min)，运行完成后可在[http://mkb.local:880](http://mkb.local:880)查看及调试网页
-
-   >[!NOTE]
-   >此时如有问题，仍可以通过commit进行提交，提交后会触发自动化部署
-
-   >[!WARNING]
-   >服务器性能有限，且已人为将自动化部署并发数设为1，请尽可能避免在Pr后提交Commit
-
-4. 在检查完测试网页后可添加管理员作为评审人，之后须有管理员评审并在通过审核后将分支合并至主分支
-
-   ![PR_Review](./Readme/img/PR_Review.png)
-   ![PR_Review_Judge](./Readme/img/PR_Review_Judge.png)
-
-5. 最后需管理员手动合并测试网页至正式版网页   
@@ -1,171 +0,0 @@
-# Git 与 Gitea 协作开发指南
-
-## 文档说明
-
-本文档面向公司内部已配置好开发环境（VSCode、Git、Gitea）的同事，旨在规范并指导如何使用 Git 和公司内网的 Gitea 服务平台进行高效的日常代码协作。本文档不包含环境安装与部署内容。
-
-## 1. 术语表 (Glossary)
-
-| 术语/缩写 | 全称/解释 | 说明 |
-| :--- | :--- | :--- |
-| **Repository (Repo)** | 仓库 | 一个项目所有的文件和历史记录。可以理解为你的项目文件夹及其所有变更记忆。 |
-| **Local** | 本地 | 指存储在你个人电脑上的仓库。 |
-| **Remote** | 远程 | 指存储在服务器（如 Gitea）上的仓库，是团队协作的中心。 |
-| **Clone** | 克隆 | 将**远程仓库**完整下载到本地的操作。这是获取项目代码的起点。 |
-| **Commit** | 提交 | 将你的代码变更**打包并保存**到本地仓库历史记录中的操作。每次提交都需要一条说明信息。 |
-| **Push** | 推送 | 将你本地仓库的提交**上传**到远程仓库的操作，使你的工作成果对他人可见。 |
-| **Pull** | 拉取 | 将远程仓库的最新提交**下载并合并**到本地的操作，用于同步他人的工作成果。 |
-| **Fetch** | 获取 | 从远程仓库**下载**最新的变更信息到本地，但**不会自动合并**到你的工作文件中。让你可以查看他人进度，再决定是否拉取。 |
-| **Branch** | 分支 | 一条独立的开发线。主分支（如 `main`）应保持稳定，新功能应在**特性分支**上开发。 |
-| **Merge** | 合并 | 将一个分支的修改整合到另一个分支的操作（例如，将功能分支合并到主分支）。 |
-| **Pull Request (PR)** | 拉取请求 | **一个核心协作流程**。它是 Gitea 等平台的功能，用于发起代码合并请求，并进行代码评审（Code Review）、讨论和自动化检查。 |
-| **Issue** | 议题/问题 | 用于**跟踪任务、功能请求和 Bug**。每个 Issue 应有清晰的标题和描述，可以被分配、分类和讨论。 |
-| **`.gitignore`** | - | 一个特殊的配置文件，用于告诉 Git 哪些文件或目录**不需要**纳入版本控制（如日志文件、编译产物、本地配置文件等）。 |
-| **Conflict** | 冲突 | 当多个人修改了同一文件的同一区域时，Git 无法自动合并，需要**人工介入**解决的情况。 |
-| **HEAD** | - | 通常指向你当前所在的分支的最新提交，可以理解为“你当前的工作目录状态”。 |
-
---
-
-## 2. 核心工作流程
-
-### 2.1. 初始化：克隆仓库 (Clone)
-
-参与一个已有项目的第一步是获取代码。
-
-1.  打开浏览器，访问项目的 Gitea 页面。
-2.  找到并点击 **克隆** 按钮，复制提供的 URL（通常以 `http://...` 开头）。
-3.  在 VSCode 中：
-    *   按 <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> 打开命令面板。
-    *   输入 `Git: Clone` 并选择。
-    *   粘贴刚才复制的 URL，按回车。
-    *   选择本地存储项目的目录。
-4.  克隆完成后，VSCode 会提示你打开克隆的项目。
-
-### 2.2. 每日循环：获取与同步
-
-**每天开始工作前**，务必先同步远程的最新代码到本地，以避免冲突。
-
-*   **推荐操作：拉取 (Pull)**
-    *   **VSCode GUI**: 点击左侧源代码管理图标 -> 点击顶部 **...** -> 选择 **拉取 (Pull)**。
-    *   **终端命令**: `git pull origin <当前分支名>`
-
-*   **可选操作：获取 (Fetch) + 拉取**
-    *   如果你想先查看别人改了什么再决定是否合并，可以先 **获取**：
-        *   **VSCode GUI**: ... -> **获取 (Fetch)**
-        *   **终端命令**: `git fetch`
-    *   获取后，你可以在 VSCode 的左下角分支状态栏或源代码管理视图看到远程的更新提示，然后再决定拉取。
-
-### 2.3. 开发流程：基于分支的策略
-
-我们采用 **功能分支工作流**。严禁直接在 `main` 或 `develop` 等主分支上直接开发新功能。
-
-1.  **创建新分支**：
-    *   确保你当前在**主分支**上（例如 `main`），并且已经执行了 **拉取** 操作。
-    *   点击 VSCode 窗口左下角的分支名 -> 选择 **创建新分支...** -> 输入分支名 -> 回车。
-    *   **分支命名规范**：
-        *   功能：`feat/简短描述`，例如 `feat/user-auth`
-        *   Bug修复：`fix/问题描述`，例如 `fix/login-crash`
-        *   文档：`docs/更新内容`，例如 `docs/api-update`
-        *   热修复：`hotfix/紧急问题`，例如 `hotfix/prod-issue`
-
-2.  **在新分支上开发**：在此分支上完成你的编码、测试等工作。
-
-3.  **提交更改**：
-    *   在 VSCode 的“源代码管理”面板，看到所有更改的文件。
-    *   点击文件旁的 **+** 号或将文件拖到“暂存更改”区域。
-    *   在上方输入框撰写**清晰的提交信息**。
-        *   **格式建议**：`[类型] 简短描述`，例如 `[Feat] 增加微信登录功能` 或 `[Fix] 修复首页图片无法加载的问题`。
-    *   按 <kbd>Ctrl</kbd>+<kbd>Enter</kbd> (Mac: <kbd>CMD</kbd>+<kbd>Enter</kbd>) 提交到**本地仓库**。
-
-4.  **推送分支**：
-    *   首次推送新分支时，VSCode 会提示你发布（推送）分支。点击提示或点击源代码管理顶部的 **...** -> **推送**。
-    *   这将把你的本地分支和所有提交推送到 Gitea，并在远程创建同名分支。
-
-### 2.4. 协作流程：发起拉取请求 (Pull Request)
-
-完成功能开发后，需要将代码合并回主分支。
-
-1.  **推送最终代码**：确保你已将分支的所有提交都推送到 Gitea。
-2.  **在 Gitea 上创建 PR**：
-    *   浏览器打开你的项目 Gitea 页面。
-    *   通常页面上会有你刚推送分支的提示，直接点击 **创建拉取请求** 按钮。
-    *   或手动切换到 **Pull Requests** 标签页 -> **New Pull Request**。
-3.  **填写 PR 信息**：
-    *   **标题**：清晰概括 PR 内容，建议使用提交信息的格式。
-    *   **描述**：
-        *   详细说明修改内容、动机、测试方法。
-        *   **关键：关联 Issue**。在描述中输入 `#` 后会提示相关的 Issue，选择即可。使用 `Closes #15`, `Fixes #32` 等关键词，合并后可自动关闭对应 Issue。
-        *   如有界面变动，最好附上截图或屏幕录制。
-    *   选择正确的**基础分支** (如 `main`) 和**头部分支** (你的功能分支)。
-4.  **发起评审**：可以指定相关同事进行评审（Review）。
-5.  **处理评审意见**：评审者可能会在 PR 中提出评论。请根据意见在本地修改代码，然后再次**提交并推送**，新的提交会自动追加到该 PR 中。
-6.  **合并与清理**：
-    *   通过评审后，由有权限的成员在 Gitea 上操作合并。
-    *   合并后，可以在 Gitea 上**删除已合并的功能分支**（通常有选项）。
-    *   **本地清理**：切换回 `main` 分支 -> 拉取最新代码 -> 删除本地已合并的功能分支 (`git branch -d feat/your-branch`)。
-
---
-
-## 3. 常见问题与解决方案
-
-### 3.1. 推送失败：非快进式更新
-
-**现象**：`git push` 时提示 `! [rejected] error: failed to push some refs...`
-
-**原因**：在你推送之前，远程分支已经被别人更新了。
-
-**解决**：
-1.  执行 `git pull origin <你的分支名>` 拉取远程的最新代码并合并到本地。
-2.  解决可能出现的**合并冲突**（见下节）。
-3.  再次执行 `git push`。
-
-### 3.2. 合并冲突 (Conflict)
-
-**现象**：执行 `git pull` 或合并分支时，提示 `CONFLICT (content)`。
-
-**解决**：
-1.  **保持冷静**，冲突是协作的正常部分。
-2.  在 VSCode 中，冲突文件会被突出显示。打开文件，你会看到 Git 的冲突标记：
-    ```python
-    <<<<<<< HEAD
-    这是你本地修改的代码
-    =======
-    这是远程分支上的代码
-    >>>>>>> commit-hash...
-    ```
-3.  **沟通与决策**：与冲突代码的作者（可通过 Git 历史或团队沟通工具联系）讨论，决定保留哪一部分代码，或进行整合。
-4.  **手动解决**：
-    *   删除不需要的代码块。
-    *   **必须删除**所有冲突标记 (`<<<<<<<`, `=======`, `>>>>>>>`)。
-5.  **标记为已解决**：
-    *   在 VSCode 的“源代码管理”面板，解决后的文件会出现在“已暂存的更改”中。
-    *   右键点击该文件 -> **选择阶段更改**（如果未自动暂存）。
-6.  **完成合并**：
-    *   像正常提交一样，输入一个合并提交信息（如 `Merge branch 'main' into feat/xxx`）。
-    *   提交并推送。
-
---
-
-## 4. VSCode 高效技巧
-
-1.  **图形化界面**：多使用“源代码管理”视图和右键菜单，大部分操作无需命令。
-2.  **差异对比**：点击更改的文件，可直观查看代码行级别的变化（绿色新增，红色删除）。
-3.  **行内暂存**：在更改文件的代码行号旁边，点击 **+** 号可以只暂存该行的修改，而不是整个文件，用于提交精炼的更改。
-4.  **集成终端**：使用 VSCode 内置终端 (<kbd>Ctrl</kbd>+<kbd>`</kbd>) 执行 Git 命令，工作流无缝衔接。
-5.  **时间线视图**：点击单个文件，在编辑区下方可以看到该文件的**时间线**，展示所有的历史提交记录，方便追溯变更。
-
-## 5. 最佳实践总结
-
-1.  **勤提交**：小步快跑，频繁提交。每次提交只做一个明确的修改，并写好清晰的提交信息。
-2.  **勤拉取**：开始工作前、提交代码前，先 `pull` 一下，与主线保持同步。
-3.  **开分支**：任何新功能或 Bug 修复，都从新建分支开始。
-4.  **早提 PR**：功能未完全完成但希望早期评审时，可以创建 **Draft PR**（Gitea 支持）。
-5.  **看提示**：密切关注 VSCode 左下角分支状态栏的同步状态提示（如 `↑3` 代表有3个本地提交未推送，`↓2` 代表有2个远程提交未拉取）。
-6.  **用 Issues**：开发前先创建 Issue 来规划和跟踪任务，并在 PR 中关联它们。
-
-## 获取帮助
-
-*   **本地帮助**：在终端输入 `git help <命令>`，如 `git help commit`。
-
-
-祝您编码愉快，协作顺利！
@@ -1,184 +0,0 @@
-
-好的，没问题。这是一份为您和您的同事准备的 Markdown 使用指南，风格和受众与之前的 Git 文档保持一致。
-
---
-
-# Markdown 协作书写指南
-
-## 文档说明
-
-本文档面向公司内部所有需要使用 Markdown 语言书写文档的同事。Markdown 是一种轻量级标记语言，允许人们使用易读易写的纯文本格式编写文档，并可转换为有效的 HTML 文档。我们将在 **VSCode** 中编写，并托管在 **Gitea** 上进行版本管理与协作。
-
-## 1. 术语表 (Glossary)
-
-| 术语 | 解释 |
-| :--- | :--- |
-| **Markdown (.md)** | 一种轻量级标记语言，使用纯文本格式的语法，使其易读、易写，并可转换为结构化的 XHTML/HTML。 |
-| **语法 (Syntax)** | 一套规则体系，定义了如何通过简单的符号（如 `#`, `*`, `-` 等）来格式化文本。 |
-| **渲染 (Rendering)** | 将 Markdown 源代码解析并转换为可视化的、格式优美的文档（如 HTML、PDF）的过程。 |
-| **预览 (Preview)** | 在编写 Markdown 时实时查看其渲染后效果的功能。 |
-| **GFM (GitHub Flavored Markdown)** | GitHub（及 Gitea）对标准 Markdown 的扩展，提供了表格、任务列表等实用功能。 |
-| **扩展语法 (Extended Syntax)** | 并非所有 Markdown 处理器都支持的额外语法，如表格、脚注、定义列表等。 |
-
---
-
-## 2. 为什么使用 Markdown？
-
-*   **通用性强**：广泛用于 `README` 文件、论坛帖子、文档、博客、代码注释等。
-*   **专注于内容**：无需关心字体、颜色等样式，只需用简单的符号定义结构。
-*   **纯文本特性**：意味着：
-    *   兼容所有文本编辑器。
-    *   非常适合用 **Git** 进行版本控制，差异对比清晰明了。
-    *   永远不会因为软件换代而过时。
-*   **可转换**：轻松转换为 HTML、PDF、Word 等多种格式。
-
---
-
-## 3. 核心语法速查表
-
-这是你最常用到的 90% 的语法。
-
-### 3.1. 标题 (Headers)
-
-使用 `#` 的数量来表示标题的级别，从 1 级（最大）到 6 级（最小）。
-
-```markdown
-# 一级标题 (H1)
-## 二级标题 (H2)
-### 三级标题 (H3)
-#### 四级标题 (H4)
-##### 五级标题 (H5)
-###### 六级标题 (H6)
-```
-
-### 3.2. 强调 (Emphasis)
-
-```markdown
-*这是斜体文本* 或 _这也是斜体文本_
-**这是粗体文本** 或 __这也是粗体文本__
-***这是粗体加斜体*** 或 ___这也是粗体加斜体___
-```
-
-### 3.3. 列表 (Lists)
-
-**有序列表 (Ordered Lists)：** 使用数字加点号
-```markdown
-1. 第一项
-2. 第二项
-3. 第三项
-```
-
-**无序列表 (Unordered Lists)：** 使用 `-`, `*`, 或 `+`
-```markdown
- 列表项
- 另一个列表项
-  - 嵌套列表项（缩进两个空格或一个制表符）
-```
-
-**任务列表 (Task Lists - GFM 特性)：** 非常适合记录待办事项
-```markdown
- [x] 已完成的任务
- [ ] 未完成的任务
-```
-
-### 3.4. 链接与图片 (Links & Images)
-
-**链接：**
-```markdown
-[显示的链接文本](https://www.example.com "悬停提示文本（可选）")
-```
-
-**图片：**
-```markdown
-![图片的替代文本(alt text)](images/logo.png "悬停提示文本（可选）")
-```
-> **最佳实践**：使用 `source\_images`  文件夹来存放图片, `source\_static`来存放静态数据，并使用**相对路径**引用，这样在 Gitea 上也能正确显示。
-
-### 3.5. 代码 (Code)
-
-**行内代码 (Inline Code)：** 用反引号包裹
-```markdown
-使用 `git commit` 命令来提交更改。
-```
-
-**代码块 (Code Blocks)：** 用三个反引号包裹，并可选指定语言以实现语法高亮
-````markdown
-```python
-def hello_world():
-    print("Hello, World!")
-```
-````
-
-### 3.6. 引用 (Blockquotes)
-
-使用 `>` 符号表示引用。
-```markdown
-> 这是引用的文本。
-> 这是引用的文本。
->
-> > 这是嵌套的引用。
-```
-
-### 3.7. 表格 (Tables - GFM 特性)
-
-使用连字符 `-` 来分隔表头，管道符 `|` 来分隔列。
-```markdown
-| 左对齐 | 居中对齐 | 右对齐 |
-| :----- | :------: | -----: |
-| 单元格 |  单元格  | 单元格 |
-| 单元格 |  单元格  | 单元格 |
-```
-
---
-
-## 4. VSCode 中的高效书写
-
-VSCode 对 Markdown 提供了强大的原生支持。
-
-1.  **实时预览 (Preview)**：
-    *   打开一个 `.md` 文件。
-    *   点击编辑器右上角的 **拆分编辑器** 图标，或按 `Ctrl+K V`（按住 `Ctrl+K`，松开再按 `V`）。
-    *   右侧将打开一个实时渲染的预览窗口，与你左侧的编辑同步滚动。
-
-2.  **快捷键与自动补全**：
-    *   **加粗**：选中文本，按 `Ctrl+B`。
-    *   **斜体**：选中文本，按 `Ctrl+I`。
-    *   **代码块**：输入三个反引号 ```` ``` ```` 后按回车，VSCode 会自动补全并让你输入语言类型。
-    *   **列表**：输入 `- ` 或 `1. ` 后，按回车会自动创建下一项。
-
-3.  **目录生成 (TOC)**：
-    *   有许多扩展可以自动根据标题生成目录（如 `Markdown All in One`）。
-    *   在 Gitea 中，仓库的 `README.md` 文件会自动根据标题生成目录。
-
-4.  **代码格式化**：
-    *   安装 `Markdownlint` 等扩展，它可以帮你自动格式化 Markdown 文档并标记出不符合规范的写法。
-
---
-
-## 5. 与 Gitea/Git 的协作
-
-1.  **版本控制**：`.md` 文件是纯文本文件，非常适合用 Git 管理。每次对文档的修改（修正错别字、增加章节）都可以清晰地通过 `git diff` 看到。
-
-2.  **Gitea 渲染**：Gitea 完全支持 GFM。你推送至 Gitea 的任何 `.md` 文件都会在网页上被自动渲染成美观的文档。
-
-3.  **使用 Issues 和 PR 协作修改文档**：
-    *   发现文档错误或想贡献内容？和代码一样：
-        1.  **Fork** 或 **Clone** 仓库。
-        2.  基于 `main` 分支创建一个新分支（如 `docs/fix-typo`）。
-        3.  修改 `.md` 文件。
-        4.  提交更改，写清提交信息（如 `[Docs] 修复用户手册中的拼写错误`）。
-        5.  推送分支并发起 **Pull Request (PR)**。
-    *   其他同事可以在 PR 中对文档修改进行**评审（Review）**，提出建议。
-
---
-
-## 6. 最佳实践与规范
-
-1.  **保持简洁**：Markdown 的哲学是易读易写。不要滥用复杂格式。
-2.  **标题层级**：从 `H1` 开始，按顺序使用，不要跳级。
-3.  **中英文混排**：中英文之间加一个空格，例如：“学习 Markdown 语言” 而不是 “学习Markdown语言”。
-4.  **统一的图片管理**：在项目根目录建立 `assets` 或 `images` 文件夹，所有图片统一放入。
-5.  **行尾不要留空格**：这可能会在某些渲染器中导致意外的换行。
-6.  **善用代码块**：对于命令行操作、配置代码等，务必使用代码块，提高可读性。
-
-现在，你可以开始使用 Markdown 高效、优雅地书写所有文档了！
@@ -1,81 +0,0 @@
-# 自研DPS验证测试报告_20251030
-
-## 1. 测试概述
-
-### 1.1 测试目的
-
-验证自研DPS板卡功能及性能指标
-
-### 1.2 测试对象
-
- **设备型号**: New_DPS
- **硬件版本**: N_JC025M005_A4
- **固件版本**: ARM==20251024
- **序列号**: NT25060801002
-
-### 1.3 测试环境
-
- **测试平台**: Mars_2K
- **测试工具**: 示波器、八位半
- **环境温度**: 24°C ± 2°C
-
-## 2. 测试项目与结果
-
-### 2.1 电源测试
-
-| 测试项目 | 实测结果 |
-|---------|----------|
-| 输入电压 | 20V-24V |
-| -16VA纹波 | 9.6549W |
-| -16VB纹波 | 15.631mV |
-| -16VC纹波 | 17.470mV |
-| GND噪声 | 16.781mV |
-
-### 2.2 功能测试
-
-| 功能模块 | 测试方法 | 预期结果 | 实际结果 |
-|----------|----------|----------|----------|
-| ForceV | FVMV/FVMI @ 10Ω/Hi-Z All Channel | ForceV -15V~15V | [Note1](#custom-anchor1) |
-| ForceI | FIMV @ 10Ω All Channel| ForceI according to range | [Note1](#custom-anchor1) |
-| MeasureV | FVMV/FIMV @ 10Ω All Channel|  | [Note2](#custom-anchor2) |
-| MeasureI | FVMI @ 10Ω All Channel|  | [Note2](#custom-anchor2) |
-|ClampV| FIMV @ 10Ω All Channel|| Pass! |
-|ClampI| FVMV/FVMI @ 10Ω All Channel| | Fail! [Note3](#custom-anchor3) |
-
-## 3. 问题
-
-### 3.1 发现的问题
-
-1. Force存在±10mV抖动 <a id="custom-anchor1"></a> 
-
-2. 取得正确的测量结果的流程较为复杂，需： <a id="custom-anchor2"></a> 
-   1. 在取得初始值前通过ATE_Debugger发送指令：newdpsfunc("newdpsinitvalue","enable");
-   2. 上位机连接获取初始值
-   3. 检查初始值无误后上传初始值至Zynq中
-   4. 通过ATE_Debugger发送指令：newdpsfunc("newdpsinitvalue","disable");
-   5. 执行测量
-
-3. 在ClampI模式下(FVMV/FVMI)，若Clamp值与Force值接近(如80mA档位Clamp60mA,Force70mA;2mA档位Clamp1mA,Force1.5mA)则Force输出与Sense管脚及对应信号链均会出现震荡，且在极端情况下震荡 ***可能不收敛*** <a id="custom-anchor3"></a> 
-
-![ClampI2](../../_images/NewDPS/clamp_001.bmp)
-
-![ClampI](../../_images/NewDPS/clamp_003.png)
-
-### 3.2 原因分析
-
-1. 初步推测由地平面噪声引入，整板均存在，影响Force输出稳定性
-2. ADC计算公式不同，现通过固件进行区分修正，导致需额外指令切换计算公式，猜测固件通过映射初始值进行转换
-3. 由于Clamp经过采样电阻后作为反馈输入运放构成Clamp电压，但其反馈、试探过程时间较长且可能导致不收敛，在这过程中输出电压不受控
-
-## 4. 测试结论
-
-Force存在噪声影响稳定性，Measure欲获得正确回读值需发送指令，过程较为复杂，Clamp除短路时生效外基本无实用意义
-
---
-
-## 附件：
-
-1. -16VA纹波 ![-16V_A](../../_images/NewDPS/15V0.png)
-2. -16VB纹波 ![-16V_B](../../_images/NewDPS/15V1.png)
-3. -16VC纹波 ![-16V_C](../../_images/NewDPS/15V2.png)
-4. [ClampI波形(WFM格式)](../../_static/data/NewDPS/Waveform/ClampI.7z)
@@ -1,10 +0,0 @@
-##############################
-自研板卡测试报告
-##############################
-
-.. toctree::
-   :maxdepth: 1
-   :caption: Contents:
-   :glob:
-
-   *
@@ -12,4 +12,3 @@ Hardware Verification
   Load_Verify/index
   Cal/index
   PPMU2.0/index
-   Custom_Board/index
@@ -1,98 +0,0 @@
-
-# 实验报告：<在此填写实验名称>
-
-## 基本信息
-| 项目         | 内容                  |
-|--------------|-----------------------|
-| 实验日期     | `YYYY-MM-DD`          |
-| 负责人       | `沈浴阳`              |
-| 报告版本     | `V1.0`                |
-| 板卡编号     | ``              |
-
---
-## 一、实验背景
-
---
-
-## 二、实验目的
-<!-- 清晰描述实验要验证的关键问题 -->
-1. 目标1：`<验证XXX功能/性能>`
-2. 目标2：`<测试XXX极限参数>`
-3. 目标3：`<对比XXX设计方案>`
-
---
-
-## 三、实验环境
- **硬件配置**  
-  `<被测设备型号> + 配套设备列表>`
- **软件环境**  
-  `<测试软件及版本>`
- **物理环境**  
-  `温度：25±2℃ | 湿度：45±5%RH`
-
---
-
-## 四、实验步骤
-### 1. 准备工作
-<!-- 分步骤描述准备过程 -->
-1) 步骤描述1：`<连接XX设备到XX接口>`
-2) 步骤描述2：`<设置XX参数为XX值>`
-   ![](./images/step2_setup.jpg) <!-- 建议图片命名：stepX_description.jpg -->
-
-### 2. 测试流程
-<!-- 按顺序记录关键操作 -->
-```mermaid
-graph LR
-A[启动设备] --> B{监测初始状态}
-B -->|正常| C[执行测试用例1]
-B -->|异常| D[记录故障现象]
-C --> E[采集数据]
-```
-
---
-
-## 五、实验结果
-### 关键数据记录
-| 测试点 | 预期值 | 实测值 | 偏差 | 单位 |
-|--------|--------|--------|------|------|
-| Vout   | 3.3    | 3.28   | -0.6% | V    |
-| I_max  | 2.0    | 2.15   | +7.5% | A    |
-
-### 波形/现象记录
-**图1：上电冲击电流波形**  
-![](./images/inrush_current_20230501.png)  
-*注释：观测到XX μs的浪涌电流*
-
-**图2：高温测试红外热像**  
-![](./images/thermal_image_test3.jpg)  
-*注释：芯片最高温度达XX℃（环境XX℃）*
-
---
-
-## 六、问题分析
-<!-- 使用故障树等结构化方法 -->
-```mermaid
-graph TD
-A[异常现象] --> B[电源模块]
-A --> C[信号干扰]
-B --> D{排查方向1}
-C --> E{排查方向2}
-```
-
---
-
-## 七、结论与建议
-✅ **实验结论**  
-1. `<验证通过/未通过的指标>`
-2. `<关键发现>`
-
-⚠️ **改进建议**  
- [ ] 建议1：`<硬件优化方案>`
- [ ] 建议2：`<测试方法改进>`
-
---
-
-## 附件
-1. [原始数据文件](./data/rawdata_20230501.csv)
-2. [电路原理图](./schematics/v2.0_final.pdf)
-3. [测试视频](./videos/test_recording.mp4)
Author	SHA1	Message	Date
yuysh	c6f664085e	Updated workflow Build Sphinx Documentation / Build Documentation from PR Branch (pull_request) Successful in 2s Details	2026-04-13 13:34:06 +08:00
yuysh	2147dc4082	Upgrade to python3 Build Sphinx Documentation / Build Documentation from PR Branch (pull_request) Failing after 0s Details Deploy Sphinx Documentation / deploy (pull_request) Successful in 1s Details	2026-04-13 13:28:35 +08:00