一段临时脚本通过聊天发出去，很快就会出现几个版本：哪个修了路径，哪个增加了参数，哪个才是最后一次能用的文件。Opengist 将代码片段保存在 Git 仓库中，提供网页编辑、修订差异与下载入口，适合管理需要反复引用的小段代码和说明。
它适合代码片段，不必承担完整项目仓库的全部流程。部署前先选一个无敏感信息的样本，例如读取一份测试 CSV 的脚本，加一份 Markdown 使用说明，再改动一次参数。看见版本差异和原文件下载正常，再放入真正需要维护的资料。
官方示例展示代码片段与修订入口，布局按所部署版本核对。
部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。
public、unlisted 与 private 要实际试一次
公开、未列出与私密是不同状态。未列出通常不出现在发现列表中，但持有链接的人仍可能访问，不能当作严格私密。账号登录也不意味着自己新建的所有片段默认采用同一个安全范围，保存之前检查每条记录的可见性。
用两个浏览器会话验证：一个登录自己的账号，另一个不登录。分别打开三类测试片段的页面、原始文件和下载入口，确认行为符合当前版本规则。需要团队访问时，再用另一账号检查其权限，不要只看管理员自己的页面。
代码中不要保存密码、令牌、数据库连接串或个人资料。Git 修订会保留历史，后来删掉一行秘密，不等于旧修订已经消失。发现凭据曾被提交时，应先撤销并替换凭据，再按实际需要处理历史副本，而不是仅在最新页面遮住它。
第一名注册用户拥有管理员入口
官方文档说明，实例创建的首个用户可以进入 Admin 面板。初始设置因此要在私人入口完成，不能把空实例直接放到公网等自己稍后注册。本例先只绑定 VPS 本机 HTTP 端口，不开放 Git SSH 端口。
VPS 需安装 Docker Engine 与 Compose 插件，有 SSH 登录权限。本例固定为官方 README 所列的 ghcr.io/thomiceli/opengist:1.15.2，持久目录 /opengist，HTTP 端口 6157。这个标签是本文核对过的示例版本，不表示将来始终是最新版本。
mkdir -p /opt/opengist
cd /opt/opengist
mkdir -p data
建立 compose.yaml：
services:
opengist:
image: ghcr.io/thomiceli/opengist:1.15.2
restart: unless-stopped
ports:
- "127.0.0.1:6157:6157"
volumes:
- ./data:/opengist
docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=100 opengist
在自己的电脑运行以下隧道，再打开 http://localhost:16157：
ssh -N -L 16157:127.0.0.1:6157 user@VPS_IP
注册第一个账号，设置独立强密码，然后进入 Admin。私人实例可以开启 Disable signup 与 Require login。另有允许个别片段免登录访问的选项，启用前检查它与要求登录之间的作用范围，不要一边限制发现列表，一边忘记直接下载仍可能公开。
保存配置后退出账号，在全新会话中再试注册、浏览与下载。创建一条样本，更新内容并重启容器，确认修订与文件都保留。数据目录权限有问题时先查看日志，默认镜像的启动方式与显式 user 模式不同，不要混用多个旧教程的目录所有权设置。
准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。
给片段留一份真正可执行的说明
片段名称写清用途，说明中保留输入文件格式、所需软件版本、执行目录与预期输出。把所有内容都命名成“脚本”“测试”“最终版”，搜索时依然会失去方向。涉及环境变量时给出无秘密的变量名与来源，不能让使用者猜账号和路径。
修改后查看差异，尤其是引号、空格、文件路径和参数默认值。网页语法高亮可以方便阅读，但不会证明脚本正确。先在独立测试目录用小样本运行，需要删除、覆盖或访问外部系统的脚本，应把目标路径与影响范围写清楚。
多文件片段适合将脚本与 README 放在一起。下载 ZIP 后再运行，也应核对文件编码与换行，别把聊天转发过程中损坏的版本作为基准。已经进入完整开发流程的代码，迁移到正常项目仓库更便于管理测试与依赖。
需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。
HTTP Git 与服务器 SSH 是两回事
本例没有映射容器 2222，因此不能直接照其他教程使用该端口克隆。日常 SSH 登录 VPS 的端口也不是 Opengist 的 Git SSH 服务。希望启用 Git 推送时，按官方 Git 接入说明配置独立端口、外部地址与用户密钥，并用测试仓库验证读写。
网页和 HTTP 接入长期使用应经过独立 HTTPS 子域名，反向代理指向本机 6157。检查登录、上传、原始文件下载、修订页面与实际克隆地址。代理可访问与 Git 客户端可认证是两项检查，不能互相代替。
开启 OAuth 或其他身份提供方时，另行核对回调地址与管理员身份，先保留能正常登录的管理通道。本例没有配置外部身份提供方，也没有因为项目支持这些功能就假定它们已经可用。
恢复必须保住仓库和数据库
Opengist 的内容包含 Git 仓库，账号与元信息还依赖数据库。只备份一个 ZIP 片段不能恢复完整实例。默认 SQLite 部署应保存整个 /opengist 对应目录、配置和镜像版本，停止写入后归档，再把副本复制到 VPS 之外。
cd /opt/opengist
umask 077
mkdir -p backup-out
docker compose stop opengist
sudo tar -czf "backup-out/opengist-$(date +%F-%H%M%S).tgz" data compose.yaml
docker compose start opengist
采用外部 PostgreSQL 或 MySQL 的实例必须另存数据库导出，不能直接沿用这里只有目录的方案。若配置了外部秘密或会话密钥，也要按实际存放位置一并保存。备份可能含旧修订里的敏感内容，应和正式数据同样保护。
在独立目录以不同本机端口恢复原版本，核对登录、片段列表、原文件、历史差异和三种可见范围。原先用过 Git 客户端的，再验证一次只读克隆；恢复副本先不要接正式推送入口，避免两套实例各收到新的修改。
真正值得长期保留的片段，应有清楚的用途、能核对的修订和一份可取回的副本。下一次再用它时，先看适用版本与说明，再执行代码。