做网站的人手里有两三个站很正常。但如果你做的是站群、矩阵号、或者帮客户维护一批网站，数量上了10个以上，代码版本管理就从一个"顺手做"的事变成了噩梦。
模板文件改了一个公共函数，20个站要逐个替换；某个站出了bug，想知道是哪次改动引入的，但目录散落在不同服务器上根本找不到变更记录；换个服务器环境部署，每个站要手动重新配一遍。这些问题单靠FTP上传覆盖是解决不了的，必须上版本管理。但Git是为单个项目设计的，10个以上的仓库怎么批量管？
多仓库管理的三种典型场景
| 场景一 | 每个网站一个独立Git仓库，代码完全独立，但底层有共享组件 |
| 场景二 | 一套核心代码部署到多台服务器，每台有少量配置差异 |
| 场景三 | 客户定制站，每个客户一个分支，主分支更新后要同步到所有客户分支 |
三种场景的工具选择完全不同，用错工具比不用工具还折腾。
场景一：30个独立仓库，每天要git pull 30次
这是最常见的情况。每个网站代码结构差不多但内容不同，各自一个Git仓库。日常操作就是"改完代码、commit、push、然后去服务器上pull"。仓库少的时候手动操作就行，上了10个以后，光pull一圈就要十几分钟。
批量管理的核心需求就是一句话：一条命令，对所有仓库执行同一个操作。
能满足这个需求的工具不少，但用起来差别很大：
| 工具 | 核心特点 | 上手难度 | 适合场景 |
|---|---|---|---|
| gitbatch | YAML配置仓库列表，支持并行操作，可视化状态面板 | ⭐ 低 | 10-50个仓库，日常pull/push/status |
| myrepos (mr) | 不限于Git，支持svn/hg等，可自定义操作脚本 | ⭐⭐ 中 | 混合版本控制系统，需要自定义操作 |
| gita | Python写的，彩色输出，专注状态查看和基本操作 | ⭐ 低 | 10-100个仓库，偏查看和轻量操作 |
| MGit (百度开源) | Ruby封装，支持安全检查和关联操作 | ⭐⭐ 中 | 有依赖关系的多仓库，需要安全检查 |
| gitb (Rust) | Rust编写，并行执行，速度最快 | ⭐ 低 | 100+仓库，追求速度 |
站长场景推荐 gitbatch
理由很简单：用一个YAML文件列出所有仓库路径，然后gitbatch pull 一条命令搞定所有仓库的更新。不需要学新语法，底层就是普通的git命令，只是帮你自动遍历所有仓库。
gitbatch的配置文件大概长这样：
repos:- path: /www/wwwroot/site1name: 主站-产品展示branch: main- path: /www/wwwroot/site2name: 行业站Abranch: main- path: /www/wwwroot/site3name: 行业站Bbranch: dev# ... 继续添加# 常用命令：# gitbatch status → 查看所有仓库状态# gitbatch pull → 批量拉取最新代码# gitbatch log -5 → 查看所有仓库最近5条提交
场景二：一套代码跑20台服务器，配置各有不同
很多做站群的站长会遇到这种情况：网站代码几乎一样，但数据库配置、域名、Logo、统计代码每个站不同。如果每次改代码都要20台服务器各改一遍，工作量直接爆炸。
这种场景下，纯Git批量工具不够用了。需要的是"代码+配置分离"的管理方案：
推荐的目录结构：
/www/wwwroot/├── core/ ← 公共代码库（一个Git仓库）│ ├── src/│ └── templates/├── sites/│ ├── site1/│ │ ├── config.php ← 站点独有配置│ │ └── uploads/│ ├── site2/│ │ ├── config.php│ │ └── uploads/│ └── site3/│ ├── config.php│ └── uploads/└── deploy.sh ← 批量部署脚本
核心思路：
· 公共代码放在一个Git仓库里，版本管理只管理这一个仓库
· 每个站点的配置文件（数据库密码、域名等）放在各自目录下，不进Git
· 用部署脚本把公共代码同步到各个站点目录
部署脚本不需要复杂，一个简单的bash就能搞定：
#!/bin/bash# 批量部署到所有站点SITES=("site1" "site2" "site3" "site4" "site5")CORE_DIR="/www/wwwroot/core"SITES_DIR="/www/wwwroot/sites"for site in "${SITES[@]}"; doecho "正在部署: $site"# 同步代码，排除config.phprsync -av --exclude='config.php' --exclude='uploads/' \"$CORE_DIR/" "$SITES_DIR/$site/"echo "$site 部署完成"doneecho "全部站点部署完成"回滚也很简单——Git checkout到上一个版本，重新跑一遍部署脚本。20个站点3分钟内全部回滚到上一个稳定版本。
场景三：给客户定制站点，主版本更新后怎么同步
假如你做了一个CMS模板，卖给了30个客户。每个客户要求的功能和样式不太一样，你给每人开了一个分支。现在主模板升级了一个安全漏洞，怎么让30个分支都同步到这个修复？
这是多分支管理的经典问题。Git本身提供了两个方案：git cherry-pick 和 git rebase。
| 方案 | 适用情况 | 风险 |
|---|---|---|
| cherry-pick | 只同步某几个commit（如安全修复） | 低，只影响指定commit |
| rebase | 需要把主分支所有新改动同步过来 | 高，可能产生大量冲突 |
实操中，cherry-pick更稳妥。先在主分支上修复漏洞，然后写一个脚本批量cherry-pick到所有客户分支：
# 先获取安全修复的commit hashFIX_COMMIT="abc123def456"# 遍历所有客户分支BRANCHES=("client-a" "client-b" "client-c" "client-d")for branch in "${BRANCHES[@]}"; dogit checkout $branchgit cherry-pick $FIX_COMMITgit push origin $branchecho "已同步修复到 $branch"donegit checkout main如果不想折腾命令行，这3个带界面的方案更省心
不是所有做网站的人都习惯敲命令。下面三个方案适合想要"能看、能点、能回滚"的站长：
1. GitLab / Gitea 自建仓库 + Web界面管理
在自己的服务器上搭一个GitLab或轻量的Gitea，所有网站的代码都托管在上面。Web界面可以直接查看每个仓库的状态、提交历史、分支差异。关键是自带CI/CD功能，可以配置"推送到某分支后自动部署到服务器"。
优点：有Web界面、有权限管理、有自动部署、有Issue追踪
成本：Gitea几乎不占资源，1核2G服务器就能跑
适合：需要团队协作、需要自动部署、不想在命令行里摸黑操作
2. VS Code + 多仓库工作区
VS Code支持多根工作区（Multi-root Workspace），可以把所有网站目录加到一个工作区里。配合GitLens插件，能在侧边栏看到每个仓库的状态、分支、未提交更改。改代码时Source Control面板会显示所有仓库的改动，提交时可以选择只提交某一个仓库。
3. 宝塔面板 + Git管理插件
如果你的服务器用的是宝塔面板，可以装Git管理插件。在面板里直接配置每个站点的Git仓库地址和分支，点一下就能拉取更新、切换分支。支持Webhook自动触发——代码推送到Git仓库后，宝塔自动执行pull。
⚠️ 安全提醒
不管是自建GitLab还是用宝塔插件，配置文件一定不要进Git仓库。数据库密码、API密钥这些写到.gitignore里。建议在仓库里放一个config.example.php模板文件，部署后手动复制为config.php并填入真实信息。
版本管理搞好了，这几个连带问题也解决了
一旦把所有网站代码都纳入了版本管理，下面几个让站长头疼的问题自动就有了答案：
"昨天还好好的，今天怎么坏了？" → git log --since="2 days ago" 看最近两天谁改了什么。
"客户说上个月的版本更好看，能改回去吗？" → git checkout <commit-hash> 回到任意历史版本，3秒钟。
"这个bug是哪个版本引入的？" → git bisect 二分法定位，不用一个个版本人工测试。
"A站和B站代码有什么不同？" → git diff branchA..branchB 差异一目了然。
选工具只看一个问题
你的仓库数量有没有超过10个？
不超过10个 → VS Code多工作区 + 手动操作就够了，不需要额外工具
10-50个 → gitbatch，配置一次YAML，日常用3条命令：status、pull、log
50-100个 → gita，彩色输出让你一眼看出哪个仓库出了问题
100个以上 → gitb（Rust版），并行执行不卡顿
代码高度同质化 → 别用多仓库方案了，改成"核心仓库+配置分离+批量部署脚本"
别一上来就上最复杂的方案。工具是帮你省时间的，不是让你花时间学工具的。
版本管理这件事，最大的阻力其实不是工具，是习惯。很多人做网站是从FTP上传改文件起步的，觉得"改了直接传上去"最快。但一旦网站数量上去了、改动的复杂度上去了，没有版本记录就意味着：出了事不知道谁改的、想回滚没有存档、多个人同时改同一个文件互相覆盖。
花半天时间把所有网站代码纳入Git管理，配好批量操作工具，后续每次改代码都能省掉一大半机械操作。这笔时间账，怎么算都划算。
