博客园  :: 首页  :: 联系 :: 管理

从文件堆积到版本可控：用 Git、GitHub 与 Gitee 管理 AI 资产

Posted on 2026-07-19 17:36  天戈朱  阅读(2)  评论(0)    收藏  举报

在设计 AI 自动化流程时，一个任务通常要经过多轮交互和反复调试。过程中会不断生成脚本、配置文件、测试数据、参考文档和临时目录，最终沉淀下来的 Skill 也会持续迭代，逐渐堆积出多个难以区分的版本。

需要纳入管理的，不只是代码，还包括 Skill、技术文档、脚本、模板和图片等各类 AI 资产。它们都需要统一存储、持续维护，并能够随时追踪、恢复和复用。

为此，可以用 Git 记录每一次变化，以 GitHub 作为主仓库和发布源，通过 Gitee 建立国内镜像；图片等需要对外访问的资源，则通过公开仓库与 CDN 提供稳定访问。整个过程统一在 VSCode 中完成编辑、提交与日常管理。

让每一次修改可追踪，每一个版本可发布，每一份资产可恢复。

一、安装 Git：让文件具备版本管理能力

整套流程的基础不是 GitHub 或 Gitee，而是安装在本地电脑上的 Git。

GitHub 和 Gitee 主要负责远程存储与同步，文件的修改记录、版本切换和提交历史，实际都由 Git 管理。因此，第一步是安装 Git，并完成基本配置。

访问 Git 官网[1] 下载安装包。安装过程中大部分选项保持默认即可。默认编辑器可直接选择 Visual Studio Code，PATH 选择 Use Git from the Windows Command Prompt，确保 Git 能在命令行和 VSCode 终端中正常使用。

安装完成后，打开 Git Bash，执行：

git --version

能够正常显示版本号，说明 Git 已经安装成功。接下来配置提交身份：

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

这两项信息会写入每一次 Git 提交，用于说明这次修改由谁完成。这里配置的是提交记录中的身份信息，不是 GitHub 或 Gitee 的登录账号，也不会自动完成远程平台认证。

最后运行：

git config --global --list

确认全局配置是否已经生效。

图片
配置通过生效示例

其中，--global 表示该配置对当前系统用户下的所有 Git 仓库生效。

如果某个仓库需要使用不同的用户名或邮箱，可以进入该仓库目录后去掉 --global 重新配置，仓库级配置会覆盖全局配置。

二、规划仓库：不同类型的资产分开管理

Git 安装完成后，下一步是在 GitHub 上创建远程仓库。

这里没有把 Skill、技术文章和图片放进同一个仓库，而是按用途拆成三个独立仓库：01_my-skills、02_my-articles、03_images-bed，三个仓库分别承担不同职责：

  • • 01_my-skills：存放 Skill、脚本、参考资料和模板，设置为 Private；

  • • 02_my-articles：存放已经公开发布的文章，设置为 Public；

  • • 03_images-bed：存放图片资源，设置为 Public。

图床仓库需要公开，否则外部 CDN 无法直接访问其中的图片。

在 GitHub 页面右上角点击： → New repository；依次创建三个空仓库。为了避免后续把本地仓库推送上来时出现文件冲突，创建时先不要初始化 README、.gitignore 和 License。

  • • gitignore：指定不需要纳入版本管理的文件，例如缓存、临时文件、密钥和本地配置；

  • • License：声明其他人可以如何使用、修改和分发仓库内容，私有仓库通常可以暂不设置。

这些文件后续可以根据实际需要，在本地创建并统一提交。

图片
GitHub 三个仓库创建完成后的列表截图

按用途拆分 Skill、公开文章和图床仓库，并根据内容决定仓库的访问权限。

三、配置 SSH：打通本地与 GitHub

仓库创建完成后，还需要建立本地电脑与 GitHub 之间的连接。

GitHub 支持 HTTPS 和 SSH 两种方式。这里选择 SSH，主要是为了减少重复认证，方便后续在 Git Bash 和 VSCode 中拉取、提交和推送仓库内容。

1、在 Git Bash 中生成 SSH 密钥：

现代系统优先推荐使用 Ed25519：

ssh-keygen -t ed25519 -C "你的邮箱"

其中：

  • • ssh-keygen：生成 SSH 公私钥；

  • • -t ed25519：指定密钥算法；

  • • -C：添加备注，通常填写邮箱，方便识别。

如果需要兼容旧环境，也可以使用 RSA：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

两条命令的主要区别在于密钥算法不同。Ed25519 的密钥更短，不需要指定长度；RSA 命令中的 -b 4096 表示生成 4096 位密钥。

本文实际使用 RSA，执行命令后按提示保存到默认位置，会生成两个文件：

~/.ssh/id_rsa       私钥，仅保存在本机
~/.ssh/id_rsa.pub   公钥，用于添加到 GitHub

私钥不能上传、转发或提交到仓库。

接下来查看并复制公钥：

cat ~/.ssh/id_rsa.pub

复制输出的全部内容，通常以 ssh-rsa 开头，以填写的邮箱备注结尾。

如果生成密钥时提示目标文件已经存在，不要直接覆盖。应先确认该密钥是否正在被其他 Git 平台或项目使用。

2、将公钥添加到 GitHub

进入 GitHub 后依次操作：

1.点击右上角头像，进入 Settings；

2.在左侧菜单选择 SSH and GPG keys；

3.点击 New SSH key；

4.Title 填写便于识别的名称，例如 My PC；

5.在 Key 中粘贴刚才复制的公钥；

6.点击 Add SSH key 保存。

3. 测试 SSH 连接

在 Git Bash 中执行：

ssh -T git@github.com

其中，git@github.com[2] 是 GitHub 的 SSH 连接地址。这里的 git 是 GitHub 规定的统一 SSH 用户名，并不是个人的 GitHub 用户名。

出现下图提示，说明 SSH 身份认证已经成功；

图片
SSH 身份认证成功，本地电脑已可以通过 SSH 连接 GitHub

其中，GitHub does not provide shell access 不是报错。它表示 GitHub 的 SSH 服务只用于 Git 仓库认证，不提供远程服务器终端登录，不影响后续拉取和推送仓库。

四、连接本地与远程仓库

GitHub 上的三个空仓库已经创建完成，本地也提前建立了对应目录。这里直接用 VSCode 打开它们的上级目录，左侧资源管理器可以同时查看三个文件夹，下方内置终端用于执行后续 Git 命令。

先在 VSCode 终端中进入需要初始化的目录，例如：cd 01_my-skills。

图片
在 VSCode 中打开目录，通过内置终端进入待初始化的仓库

1. 初始化本地仓库

执行：

git init
git branch -M main

其中：

  • • git init：将当前普通文件夹初始化为 Git 仓库，并生成隐藏的 .git 目录。该目录用于保存提交历史、分支、远程仓库配置等 Git 元数据。

  • • git branch -M main：将当前主分支统一命名为 main。

执行完成后，VSCode 会自动识别当前目录中的 Git 仓库，左侧“源代码管理”面板也会显示文件变化。

2. 创建并提交测试文件

在01_my-skills 目录中新建一个 README.md，用于验证首次提交和推送是否正常；随后在终端中执行：

git add .
git commit -m "初始化仓库"

git add . 会将当前目录中的新增和修改文件加入暂存区，git commit 则把这些变化保存为一个本地版本。

也可以在 VSCode 的“源代码管理”面板中完成相同操作：暂存文件、填写提交说明，然后点击“提交”。

3. 关联 GitHub 远程仓库

复制 GitHub 仓库提供的 SSH 地址，在终端中执行：

git remote add origin git@github.com:你的用户名/01_my-skills.git

其中：remote：管理远程仓库；origin：远程仓库的默认别名；git@github.com[2]:...：前面配置好的 GitHub SSH 地址。

可以通过下面的命令检查是否关联成功： git remote -v  正常情况下，会显示当前仓库用于拉取和推送的 GitHub 地址。

4. 完成首次推送

执行：

git push -u origin main

其中，-u 会建立本地 main 分支与远程 main 分支的跟踪关系。首次推送成功后，刷新 GitHub 仓库页面，就能看到刚才创建的 README.md。

另外两个目录采用相同方式分别初始化、提交并关联对应的 GitHub 仓库。

三个目录虽然同时显示在一个 VSCode 窗口中，但仍是三个独立的 Git 仓库，各自拥有提交历史、分支和远程地址，需要分别完成提交和推送。

5. 验证仓库状态与提交历史

初始化和提交完成后，打开 VSCode 左侧的“源代码管理”面板。正常情况下，三个目录会分别显示为独立仓库，并展示各自的当前分支、待提交文件和历史提交记录。

选中某个仓库后，可以查看：

  • • 当前是否位于 main 分支；

  • • 是否存在尚未提交的文件；

  • • 每次提交的说明、提交者和先后顺序；

  • • 当前版本与历史版本之间的关系。

图片
VSCode 源代码管理面板

图注：VSCode 已识别三个独立仓库，并可分别查看当前分支、文件变更和提交历史。

如果提交后没有待处理的文件，并且 GitHub 页面中也能看到对应提交，说明本地版本记录与远程同步均已正常建立。

五、在 VSCode 中完成提交与同步

日常操作可以直接在 VSCode 中完成，Git 负责记录版本，VSCode 作为统一操作入口。

常用流程如下：

修改文件 → 暂存更改 → 提交版本 → 推送到 GitHub

对应命令为：

git pull
git add .
git commit -m "说明本次修改"
git push

使用时重点注意：

  • • 修改前先执行 git pull，同步远程仓库的最新内容；

  • • VSCode 中的“暂存更改”用于选择哪些文件进入本次提交，对应 git add；

  • • 提交前检查文件变更，避免误提交临时文件、密钥或本地配置；

  • • 提交说明应写清本次修改内容，避免只写“修改”“更新”；

  • • git commit 只生成本地版本，执行 git push 后才会同步到 GitHub；

  • • 三个仓库相互独立，需要分别提交和推送。

不需要纳入版本管理的内容，可以提前写入 .gitignore。

保存文件只是完成编辑，提交后才会形成版本，推送后远程仓库才会更新。

六、同步到 Gitee：建立国内镜像

GitHub 作为主仓库，Gitee 用于国内访问和备份。这里采用单向同步：

本地编辑（VSCode）
    ↓
Git 提交并推送
    ↓
GitHub 主仓库
    ↓
Gitee 从 GitHub 拉取镜像

所有修改统一推送到 GitHub，Gitee 只负责同步，不作为日常修改入口。

1. 创建同名空仓库

在 Gitee 中创建 01_my-skills、02_my-articles、03_images-bed 三个与 GitHub 同名的空仓库。

创建时不要初始化 README 等文件，避免与 GitHub 中已有内容冲突。

2. 创建 GitHub 访问令牌

Gitee 需要通过 GitHub Personal Access Token 获取仓库内容。

创建时重点配置：

  • • Note：填写便于识别的名称，例如 Gitee_Mirror；

  • • Expiration：建议选 No expiration（无过期时间），省得以后续期。

  • • Scopes：勾选 repo（完整仓库权限）和 workflow。

  • • 点击 Generate token，复制生成的 token 并保存好（离开页面后就看不到了）。

3. 配置 Pull 镜像

以 01_my-skills 为例，三个仓库操作步骤一样。

填写配置：

  • • 镜像方向：选择 Pull（从 GitHub 拉取到 Gitee）。

  • • 镜像仓库：选择 要拉取的 GitHub仓库地址。

  • • 私人令牌：粘贴刚才在 GitHub 生成的 Token。

  • • 勾选 自动从 GitHub 同步仓库（这样 Gitee 会自动创建 Webhook，以后你推送 GitHub，Gitee 会自动同步）。

点击 添加，Gitee 会立即开始首次同步。

图片
Gitee 镜像配置或同步成功页面

图注：配置 Pull 镜像后，Gitee 从 GitHub 同步仓库文件及提交记录。

七、轻量图床：jsDelivr 与 Gitee 双通道

图片推送到 GitHub 后，会通过镜像同步到 Gitee，因此同一张图片可以建立两种访问地址：一条来自 GitHub 的 jsDelivr CDN，另一条直接读取 Gitee 镜像仓库中的原始文件。

Gitee 的 Pull 镜像会同步 GitHub 仓库中的分支、标签和提交记录，因此两端可以保持相同的目录结构。

1. 通过 jsDelivr 访问 GitHub 图片

jsDelivr 是面向开源文件的 CDN 服务。它从 GitHub 公共仓库获取文件并缓存，再通过 CDN 节点提供访问。

地址格式为：

https://cdn.jsdelivr.net/gh/用户名
/仓库名@main/文件路径

其中：

  • • /gh/ 表示文件来源于 GitHub；

  • • @main 表示读取 main 分支；

  • • 后半部分是图片在仓库中的完整路径。

将地址粘贴到浏览器后，如果可以直接显示图片，说明 jsDelivr 访问已经生效。

图片
浏览器通过 jsDelivr 地址打开图片

图注：jsDelivr 从 GitHub 公共仓库获取图片，并通过 CDN 地址提供访问。

2. 通过 Gitee 直接访问图片

同步到 Gitee 后，也可以通过仓库的 Raw 地址直接读取图片：

https://gitee.com/用户名
/仓库名/raw/分支名/文件路径

Gitee 上的公开仓库普遍采用 /raw/分支名/文件路径 的形式直接引用图片。

两者的区别是：

  • • jsDelivr 地址经过 CDN 缓存和分发；

  • • Gitee Raw 地址直接读取 Gitee 仓库文件，不属于 CDN；

  • • jsDelivr 可以作为主要访问地址，Gitee 地址可以作为国内访问或备用通道。

需要注意，两个仓库都必须允许目标用户访问图片；用于公开图床时，图片仓库应保持公开。图片更新后尽量使用新文件名，避免缓存或镜像同步延迟导致新旧内容不一致。

GitHub 和 Gitee 负责图片存储与版本管理，jsDelivr 提供 CDN 分发，Gitee Raw 地址提供另一条直接访问路径。

八、小结

这套方案并不复杂：用 Git 记录修改，GitHub 保存主版本，Gitee 提供国内镜像，VSCode 统一完成日常操作，公开图片则通过 jsDelivr 或 Gitee 地址访问。

建立这条链路后，Skill、文档、脚本和图片不再依赖“最新版”“最终版”区分，而是具备了可追踪、可恢复和可持续维护的版本记录。

从文件堆积到版本可控，改变的不是存放位置，而是管理 AI 资产的方式。

更佳阅读效果，请移步关注我的公众号

tgzhu_公众号

引用链接

[1] Git 官网: https://git-scm.com/[2] git@github.com: mailto:git@github.com