Git 分支管理策略：个人站长如何高效管理多个网站代码

当你手上同时维护着博客、工具站、企业展示站等多个项目时，代码管理很快就会变成一团乱麻。直接改完往服务器一丢？一旦出问题回滚都找不着北。所有项目塞一个仓库？分支命名乱七八糟，提交记录像天书。

这篇文章分享一套我长期使用的 Git 分支管理策略，专门针对个人站长"项目多、变动快、一个人干"的特点设计。不需要理解复杂的企业级 Git Flow，只需要掌握几个核心原则和命令，就能让多站点代码管理变得清晰可控。

一、个人站长代码管理的典型痛点

在谈解决方案之前，先对齐问题。以下场景如果你中了两条以上，说明需要一套分支策略：

多个网站代码混在一个文件夹里，改 A 站时不小心覆盖了 B 站的配置。
上线后发现页面样式崩了，想回退到上一个版本，但完全不知道哪个提交是"上一个可用版本"。
想测试一个新功能，直接在主分支上改，改到一半发现思路不对，想撤销但已经提交了七八次。
提交信息全是"update""fix""111""test"，过两周自己都不知道这些提交干了什么。
不同项目用不同的部署平台（如 Cloudflare Pages、Vercel、GitHub Pages），每次部署都要手动切换目录和账号。

二、核心策略：GitHub Flow 简化版

企业开发常用的 Git Flow 有 main、develop、feature、release、hotfix 五类分支，对个人站长来说太重了。我推荐的是 GitHub Flow 的简化版，只有两个长期分支 + 临时功能分支：

分支名	作用	生命周期
`main`	生产环境代码，永远保持可部署状态	长期
`gh-pages` / 平台默认分支	部分静态托管平台的自动部署分支	长期（视平台而定）
`feature/xxx`	新功能开发	临时，合并后删除
`fix/xxx`	线上问题修复	临时，合并后删除
`test/xxx`	实验性改动，不确定是否合并	临时，可保留或删除

核心原则：main 分支上的代码随时可以直接部署。任何新功能或修复，都必须从 main 切出临时分支，完成后通过 Pull Request（或本地合并）回到 main，严禁直接在 main 上开发。

三、仓库结构：单仓单站 vs 单仓多站

个人站长常见的两种组织方式：

3.1 单仓库单站点（推荐）

每个网站一个独立 Git 仓库。这是我最推荐的方式，结构清晰，和静态托管平台（Cloudflare Pages、Vercel、GitHub Pages）的自动构建逻辑天然对齐。

# 项目目录结构示例
~/projects/
├── blog/                 # 博客站
│   ├── .git/
│   ├── src/
│   ├── dist/
│   └── package.json
├── tools-site/           # 工具导航站
│   ├── .git/
│   ├── index.html
│   └── css/
└── corp-site/            # 企业展示站
    ├── .git/
    ├── index.html
    └── assets/

优点：各站点完全隔离，不会互相污染；每个仓库可以独立配置自动部署；权限管理简单。缺点：公共组件（如通用的 CSS 框架、JS 工具函数）需要在多个仓库间复制粘贴。

3.2 单仓库多站点（Monorepo）

所有站点放在一个大仓库里，用目录区分。适合站点之间共享大量代码的场景。

# Monorepo 目录结构示例
~/projects/all-sites/
├── .git/
├── sites/
│   ├── blog/
│   ├── tools/
│   └── corp/
├── shared/               # 公共组件
│   ├── css/
│   └── js/
└── package.json

优点：公共代码一处修改，所有站点受益。缺点：任一站点的问题提交都会影响整个仓库历史；静态托管平台的自动构建需要额外配置构建目录。个人站长除非有强烈的代码复用需求，否则不建议用这种方式。

我的建议：站点数量在 5 个以内时，坚持单仓单站。如果确实需要复用组件，把公共部分抽成独立的 UI 库仓库，通过 npm 或 Git Submodule 引入，而不是强行 Monorepo。

四、分支命名与提交规范

分支命名和提交信息是"给未来的自己写说明书"，现在偷懒，将来还债。

4.1 分支命名规范

# 功能开发
git checkout -b feature/add-dark-mode
git checkout -b feature/seo-meta-tags

# 问题修复
git checkout -b fix/mobile-nav-overflow
git checkout -b fix/broken-contact-link

# 内容更新（博客/文章）
git checkout -b content/new-post-2026-07
git checkout -b content/update-pricing-page

# 实验性改动
git checkout -b test/rewrite-with-vite

命名格式统一为 类型/简要描述，用英文小写，单词间用连字符。一眼就能看出这个分支是干嘛的，合并后删除时也清楚它的来历。

4.2 提交信息规范（Conventional Commits）

采用轻量版的 Conventional Commits 规范，不需要像企业项目那样严格，但至少包含类型前缀：

feat: 添加夜间模式切换按钮
fix: 修复移动端导航栏超出屏幕的问题
docs: 更新 README 部署说明
style: 调整首页按钮圆角和阴影
refactor: 将内联 CSS 提取到独立文件
chore: 更新 sitemap.xml 和 robots.txt
content: 发布新文章《xxx》

类型前缀说明：

feat：新功能
fix：修复问题
docs：文档更新
style：纯样式调整（不影响功能）
refactor：代码重构（既不新增功能也不修复问题）
chore：杂项（配置更新、依赖升级等）
content：内容更新（博客文章、产品文案等）

避免这些提交信息：update、fix、111、test、ok。它们在你写的时候很清楚，两周后就是天书。如果一次改动涉及多个文件，建议拆分成多次提交，每次只做一个逻辑单元。

五、完整工作流：从开发到上线

以下是一个典型的新功能上线流程，所有命令都经过实际验证：

5.1 开始新功能

# 确保 main 是最新的
git checkout main
git pull origin main

# 切出功能分支
git checkout -b feature/add-share-buttons

# 开发、测试、本地预览
# ... 修改代码 ...

# 提交（多次小提交优于一次大提交）
git add .
git commit -m "feat: 添加文章底部分享按钮组件"
git commit -m "style: 调整分享按钮在移动端的间距"

5.2 功能完成，合并回主分支

# 先回到 main，并更新
git checkout main
git pull origin main

# 合并功能分支（推荐用 --no-ff 保留分支历史）
git merge --no-ff feature/add-share-buttons

# 推送到远程
git push origin main

# 删除已合并的临时分支
git branch -d feature/add-share-buttons
git push origin --delete feature/add-share-buttons

5.3 紧急修复线上问题

如果上线后发现严重问题，需要立刻修复：

# 从 main 切出修复分支
git checkout main
git checkout -b fix/hero-image-404

# 修复、提交
git add .
git commit -m "fix: 修复首页大图路径错误导致 404"

# 合并并推送
git checkout main
git merge --no-ff fix/hero-image-404
git push origin main

# 清理分支
git branch -d fix/hero-image-404

提示：如果问题特别紧急，你也可以先在 main 上直接修改并推送，但事后务必补一个 fix/xxx 分支记录，保持历史清晰。更好的做法是把"禁止直接推 main"设成铁律，哪怕一个人开发也要遵守。

六、回滚与版本管理：出问题时怎么救

分支策略的价值在出问题时才真正体现。以下是几种常见回滚场景：

6.1 刚提交发现错了，还没推送

# 撤销最后一次提交，保留修改内容（回到暂存区）
git reset --soft HEAD~1

# 或者撤销提交并丢弃修改（慎用）
git reset --hard HEAD~1

6.2 已经推送到远程，需要撤销

# 查看提交历史，找到要回退的版本号
git log --oneline

# 回退到指定版本（保留本地修改）
git revert abc1234

# 或者强制回退（会改写历史，团队协作时慎用）
git reset --hard abc1234
git push origin main --force

重要：如果仓库是公开的且可能有其他人 Fork 了，严禁使用 --force，它会改写公共历史。个人站长自己的仓库一般没有这个问题，但养成用 git revert 的习惯更安全。

6.3 给稳定版本打标签

每次成功上线后，给当前 main 打一个版本标签，方便将来快速回退到"已知可用"的状态：

# 打标签
git tag -a v1.2.0 -m "上线版本：新增分享功能，修复移动端适配"

# 推送标签到远程
git push origin v1.2.0

# 查看所有标签
git tag

# 将来需要回退到这个版本
git checkout v1.2.0

七、配合自动部署：推送即上线

分支策略和自动部署结合，才能真正实现"推代码即发布"。主流静态托管平台的配置逻辑：

托管平台	自动构建触发条件	个人站长建议
Cloudflare Pages	推送到生产分支自动构建	生产分支设为 `main`，每次合并到 main 即自动部署
GitHub Pages	推送到 `gh-pages` 或 Actions 触发	用 GitHub Actions 监听 `main` 推送，自动构建到 `gh-pages`
Vercel	推送到任意分支生成预览链接，生产分支自动部署	功能分支推送后自动生成预览 URL，测试无误再合并到 main

这套流程的优势在于：功能分支可以放心乱改，不会影响线上；只有合并到 main 才会触发正式部署。即使合并后发现问题，也能通过版本标签快速回滚。

八、多站点管理：减少上下文切换

当手上同时有 5 个以上站点时，光是记清楚"现在在哪个目录、哪个分支"就很费脑子。我的几个习惯：

终端提示符显示当前分支：配置 Shell（Bash/Zsh）在命令行前面显示 Git 分支名，一眼就知道当前在哪个分支。
统一的项目根目录：所有站点放在同一个父目录下（如 ~/projects/），不要散落在桌面或下载文件夹。
固定分支命名：所有仓库统一用 main 做主分支，统一用 feature/、fix/、content/ 做前缀，切换项目时不需要重新适应。
定期清理已合并分支：每周抽 5 分钟运行 git branch --merged，把已经合并到 main 的本地分支删掉，保持分支列表清爽。

九、总结

个人站长的 Git 管理不需要照搬企业级规范，核心目标只有两个：出问题时能回滚，过三个月自己还能看懂提交历史。

记住这几条铁律就够了：

main 分支永远可部署，禁止直接在上面开发。
任何改动都从 main 切临时分支，命名用 类型/描述。
提交信息加类型前缀，描述清楚做了什么。
上线后打版本标签，方便回滚。
优先单仓单站，别为了"高级"而搞 Monorepo。

这套策略我已经用了两年多，从单博客扩展到十几个站点，代码历史始终保持清晰。花半小时把规范定下来，之后每次上线都能睡个安稳觉。