Snowbot Mechanical 仓库上传规范与 PowerShell 操作手册

PUB-2604-0015-DOC · 1.0

Barcode ARCP978SJFFK6

一、用途

本文件用于规范 Snowbot 机械结构设计文件的目录放置、正式交付路径与 PowerShell 上传操作。
适用对象:结构设计工程师、兼职工程师、外包工程师。
适用仓库:arcbos/snowbot-mechanical。
核心原则:所有正式交付必须进入 GitHub 仓库;未进入 GitHub 的内容,不视为正式交付。
说明:本文件已根据仓库当前保护策略、分支策略、周报系统、评估规则与结算规则同步更新,可作为工程交付规范、执行手册与验收依据使用。

二、仓库信息(已更新)

GitHub 组织:arcbos
仓库名称:snowbot-mechanical
仓库地址:https://github.com/arcbos/snowbot-mechanical
默认主分支:main
工程师固定工作分支:chenchao-work
可见性:private
当前仓库执行原则:
1. 本仓库为 Snowbot 机械结构唯一官方仓库。
2. 所有设计文件必须提交至本仓库。
3. 未进入仓库的内容,视为未完成。
4. 所有进度以 Git 提交记录为准。
5. 外包成果默认归公司所有。
6. 工程师不得直接在 main 分支开发或提交。
7. 工程师统一在固定工作分支上提交。
8. 正式交付、周报、评估与结算,以仓库记录和系统报告为准。

三、分支与权限规则(新增,必须执行)

1. main 为公司正式主分支,仅用于最终正式交付内容。
2. 工程师不得直接在 main 分支开发、提交或推送。
3. 工程师固定在个人工作分支上开发。
4. 当前陈超固定工作分支为:chenchao-work
5. 工程师 push 到工作分支后,系统自动创建或维护 Pull Request(PR)到 main。
6. main 仅由仓库管理员(甲方)审核并合并。
7. 未进入 main 的内容,不视为正式交付。
一句话理解:
工程师可以提交自己的工作,但不能直接碰 main。

四、仓库目录结构(按现行规则)

snowbot-mechanical/
├─ 00_admin/                # 项目管理、规范、需求文档
│  ├─ submission_notes/     # 每周一句话提交说明
│  └─ templates/            # 模板目录(工程师不得修改)
├─ 01_overall/              # 整机方案、总装结构
├─ 02_chassis/              # 底盘结构
├─ 03_mobility/             # 行走系统(轮/履带)
├─ 04_snow-head/            # 除雪机构(滚刷/螺旋)
├─ 05_power-bay/            # 电池、电源结构
├─ 06_equipment/            # 设备安装(传感器/电控)
├─ 07_body/                 # 外壳、外观件
├─ 08_interfaces/           # 安装接口、标准件接口
├─ 09_service/              # 维修拆装结构
├─ drawings/                # 工程图(PDF / DXF / DWG)
├─ exports/
│  ├─ step/                 # STEP 文件
│  ├─ pdf/                  # PDF 图纸
│  └─ dxf/                  # DXF 加工图
└─ release/                 # 冻结版本(用于生产/交付)

五、文件存放规则(按现行规则)

1. 源文件

支持类型:
- SolidWorks:.SLDPRT / .SLDASM / .SLDDRW

放置位置:

对应模块目录(如 02_chassis)

2. STEP 文件

支持类型:
- .step
- .stp

放置位置:

exports/step

3. 图纸文件

支持类型:
- .pdf
- .dwg
- .dxf

放置位置:

drawings/
或 exports/pdf
或 exports/dxf

4. 提交说明文件

支持类型:
- .md
- .txt

放置位置:

00_admin/submission_notes/

提交说明模板(极简版):

文件名:YYYY-MM-DD_[模块]_note.md

内容:
本周更新:
问题:
下一步:

示例:

2026-04-20_overall_note.md

5. 冻结版本

重要版本必须复制到 release 目录。
release 目录为唯一可生产版本。

六、Git LFS 规则(按现行仓库规则)

当前仓库已对以下文件类型启用 Git LFS:
- *.step
- *.stp
- *.SLDPRT
- *.SLDASM
- *.SLDDRW
- *.dwg
- *.dxf
- *.pdf
含义:
1. 机械结构相关大文件按 LFS 管理。
2. 工程师本地必须安装 Git 与 Git LFS。
3. 如出现大文件推送异常,应优先检查 LFS 是否安装并初始化。

七、命名规范(强制)

统一格式:
模块_部件_版本_日期

示例:

chassis_frame_V1_20260404.step
snowhead_auger_V2_20260405.SLDPRT
battery_bay_V1_20260420.pdf

禁止使用:

最终版
最新版
改改改
test
new
upload

八、工程师可修改范围与禁止范围(新增,必须执行)

工程师允许修改

00_admin/submission_notes/
01_overall/
02_chassis/
03_mobility/
04_snow-head/
05_power-bay/
06_equipment/
07_body/
08_interfaces/
09_service/
drawings/
exports/
release/

工程师禁止修改

.github/
tools/
README.md
README_AUTOMATION.md
00_admin/templates/
说明:
工程师只允许提交工程成果,不允许修改仓库规则、自动化脚本、流程配置与模板文件。

九、最低有效交付标准(当前正式规则)

每次正式交付,最低建议包含以下四项:

1. 原始设计源文件
2. STEP 或 PDF(二选一即可,最好同时提供)
3. 一句话提交说明
4. 文件进入公司指定正确路径(GitHub 仓库)

一句话原则:

源文件 + STEP/PDF + 提交说明 + 正确路径

十、ABC 评级规则(当前正式规则)

A:源文件 + STEP/PDF + 提交说明 + 正确路径
B:已有源文件,但提交仍不完整
C:无源文件或未形成有效机械交付
周度结算规则:
A = 100%
B = 60%
C = 0%
基础周费:
3000 元 / 周

A = 3000
B = 1800
C = 0

十一、正式交付判定标准

以下条件满足时,才可视为正式交付:
1. 文件已提交至 GitHub 仓库。
2. 文件位于正确目录。
3. 文件可打开、可复用、可接手。
4. 具备必要源文件或工程文件。
5. 对当前样机推进有实际作用。
6. 经系统周报识别并进入正式记录。

以下情况不构成交付:

1. 仅口头说明
2. 仅微信聊天记录
3. 仅截图或渲染图
4. 未上传到 GitHub 的本地文件
5. 无源文件或无法复用的零散文件
6. 仅存在于个人分支且未形成正式流程记录的内容

核心判定原则:

不进 GitHub,不算交付。
未进入正式流程,不算正式交付。

十二、PowerShell + GitHub 操作手册(更新版)

1. 前提准备

在开始前,需确保以下条件已满足:
1. 已安装 Git for Windows
2. 已安装 Git LFS
3. 已拥有 GitHub 账号
4. 已被授予 arcbos/snowbot-mechanical 仓库访问权限
5. 已被告知固定工作分支名称

下载地址:

Git:https://git-scm.com/download/win
Git LFS:https://git-lfs.com/

2. 获取 GitHub Personal Access Token

GitHub 推送代码时,通常不再使用账户密码,而使用 Personal Access Token。

获取路径:

GitHub 右上角头像
→ Settings
→ Developer settings
→ Personal access tokens
→ Generate new token

要求:

1. 至少授予 repo 相关权限
2. 生成后复制保存 token
3. token 只会显示一次,丢失需重新生成

3. 打开 PowerShell

例如在 D 盘创建工作目录:

cd D:\
mkdir work
cd work

4. 克隆仓库

git clone https://github.com/arcbos/snowbot-mechanical.git
cd snowbot-mechanical

说明:

1. 该命令会将远端仓库完整拉到本地。
2. 后续所有正式交付文件,都必须放在该本地仓库目录中。
3. 不允许脱离仓库单独维护交付文件夹。

5. 初始化 Git LFS(首次环境配置)

git lfs install

6. 首次切换到固定工作分支

当前固定工作分支:

chenchao-work

首次使用执行:

git checkout chenchao-work
git pull origin chenchao-work

如果本地尚未有该分支:

git checkout -b chenchao-work --track origin/chenchao-work

7. 查看当前目录结构

dir

8. 将本地工作文件放入对应目录

例如将本地文件复制到底盘目录:

Copy-Item "D:\ChenChao\SnowbotFiles\*" ".\02_chassis\" -Recurse

要求:

1. 必须按模块放入对应目录。
2. 不允许将所有文件直接丢在根目录。
3. 原始文件、STEP、工程图尽量分别归档。
4. 必须同步准备一句话提交说明文件。

9. 首次配置 Git 用户信息(仅需一次)

git config --global user.name "你的GitHub用户名"
git config --global user.email "你的GitHub邮箱"

例如:

git config --global user.name "chenchao"
git config --global user.email "your_email@example.com"

10. 每次提交前先同步分支

git checkout chenchao-work
git pull origin chenchao-work

11. 查看本次修改状态

git status

12. 添加文件到提交区

全部添加:

git add .

如仅添加某些目录:

git add .\02_chassis
git add .\exports\step
git add .\drawings
git add .\00_admin\submission_notes

13. 提交说明

git commit -m "模块_内容_日期"

示例:

git commit -m "overall_weekly_update_20260420"
git commit -m "chassis_frame_update_20260420"

要求:

1. 提交说明必须写清楚本次提交内容。
2. 提交说明应简洁、可读。
3. 禁止使用 update、test、aaa、Add files via upload 等无意义说明。

14. 推送到远端固定工作分支

git push origin chenchao-work
注意:
1. 不允许 push 到 main。
2. main 为正式主分支,工程师不得直接提交。
3. 工程师统一 push 到固定工作分支。

15. PR 机制说明(新增)

1. 当工程师 push 到固定工作分支后,系统会自动创建或维护 Pull Request(PR)到 main。
2. 工程师不需要手工向 main 提交。
3. main 仅由管理员审核并合并。
4. 未进入 main 的内容,不视为正式交付。

16. 日常标准流程(工程师必须按此执行)

cd D:\work\snowbot-mechanical
git checkout chenchao-work
git pull origin chenchao-work

# 放入新文件或修改文件

git status
git add .
git commit -m "模块_内容_日期"
git push origin chenchao-work

17. 验证是否成功

推送成功后:

1. 检查 Git push 是否成功。
2. 检查 GitHub 上 chenchao-work 分支是否已更新。
3. 检查系统是否已自动创建或更新 PR。
4. 检查文件是否出现在正确目录。

PowerShell 中查看最近提交记录:

git log --oneline -n 5

十三、常见错误与处理

1. 权限错误

原因:未被授予仓库权限,或 token 权限不足。
处理:检查仓库权限和 token 设置。

2. 认证失败

原因:推送时填写了 GitHub 登录密码,而不是 token。
处理:重新输入 Personal Access Token。

3. 分支错误

原因:在 main 分支上操作,或切错分支。
处理:切回固定工作分支。

处理命令:

git checkout chenchao-work
git pull origin chenchao-work

4. 分支冲突

原因:本地分支落后于远端。
处理:先拉取远端分支更新。
git pull origin chenchao-work

5. 大文件或 LFS 文件推送失败

原因:Git LFS 未安装、未初始化,或本地 LFS 配置异常。
处理:检查 Git LFS 是否安装,并重新执行 git lfs install。
git lfs install

6. 无法进入 main

原因:main 已受保护,工程师没有直接 push 权限。
处理:这是正常机制。工程师应只提交到固定工作分支,不得尝试直接 push main。

十四、最终执行要求

从正式执行日起,所有结构交付统一按本文件执行。

即:
1. 文件必须按仓库目录归档。
2. 必须有源文件。
3. 必须在 GitHub 可追踪。
4. 必须可复用、可接手。
5. 必须对样机推进有实际作用。
6. 必须提交到固定工作分支。
7. 不允许直接碰 main。
8. 正式交付最终以进入 main 和系统记录为准。
后续所有进度确认、有效提交认定与结算,统一以 GitHub 仓库正式记录与系统周报为准。

一句话原则:

不进 GitHub,不算交付;
不按流程,不算正式交付。