一个人开发也要用 Git：WordPress 项目的版本管理入门

「我就一个人开发，用 Git 干嘛？」

这个想法很常见，也是错的。Git 对一个人的价值不比团队小，只是价值点不一样。

团队用 Git 是为了协作不冲突；一个人用 Git 是为了敢改代码。

一、一个人用 Git 到底能得到什么

1. 无限撤销

改了三个文件，改崩了，不确定是哪一处的问题。没有 Git：凭记忆改回去，越改越乱。有 Git：一条命令回到改动前。

2. 知道「改了什么」

两周前你改了一个功能，现在出问题了。你还记得改了哪几行吗？Git 记得。

3. 实验不心慌

想试试一个新方案，但怕改坏现有的。用 Git 开个分支，随便试，试砸了删掉分支就行，主分支一点没动。

4. 一份免费的异地备份

把代码推到 GitHub / Gitee / 自建 Git 服务，你的主题代码就有了一份异地备份。服务器挂了，代码还在。

注意：这只备份代码，不备份数据库和上传的图片。别以为推了 Git 就等于全站备份了。

二、WordPress 项目该把什么放进 Git

这是最关键的问题。答案是：

用 .gitignore 排除

在项目根目录放一个 .gitignore 文件：

# 数据库配置（绝对不能提交）
wp-config.php

# 上传的文件
/wp-content/uploads/
/wp-content/upgrade/

# WordPress 核心（如果整站在仓库里）
/wp-admin/
/wp-includes/
/wp-*.php
/index.php
/xmlrpc.php

# 缓存
/wp-content/cache/
/wp-content/advanced-cache.php

# 系统和编辑器文件
.DS_Store
*.log
/node_modules/

# 备份文件
*.sql
*.tar.gz

三、推荐的仓库结构

两种做法：

做法 A：只把主题放进仓库（推荐新手）

my-theme/
├── style.css
├── functions.php
├── index.php
├── single.php
├── .gitignore
└── ...

仓库就放一个主题目录。简单清晰，不会有误提交核心文件的风险。

做法 B：整个 wp-content 放进仓库（推荐进阶）

wp-content/
├── themes/
│   └── my-theme/        ← 进仓库
├── plugins/
│   ├── my-plugin/       ← 进仓库
│   └── third-plugin/    ← gitignore 排除
├── uploads/             ← gitignore 排除
└── .gitignore

好处：能追踪第三方插件的版本变化（如果你打算记录）。坏处：配置 .gitignore 要小心。

四、最小可用的 Git 流程（一个人够用）

你不需要学会 Git 的全部。下面这几条命令，覆盖 95% 的日常场景。

初始化

cd 你的主题目录
git init
git add .
git commit -m "初始提交"

日常：改完代码提交

# 看看改了哪些文件
git status

# 看看具体改了什么内容
git diff

# 提交
git add .
git commit -m "修复产品页价格显示"

改崩了，回退

# 放弃某个文件的所有改动，回到上次提交的状态
git checkout -- functions.php

# 放弃所有改动（谨慎！）
git reset --hard

# 回到某一次提交
git log --oneline          # 先找到那次提交的编号
git checkout abc1234 .     # 把文件恢复到那次的状态

开分支做实验

git checkout -b 新功能      # 开分支并切换过去
# ...随便改...
git checkout main           # 切回主分支（新分支的改动不影响这里）
git branch -D 新功能        # 实验失败，删掉分支

推送到远程（备份）

git remote add origin https://github.com/你的账号/仓库名.git
git push -u origin main

# 之后每次
git push

五、提交信息怎么写（给未来的自己看）

很多人写 git commit -m "更新" 或者 -m "fix"。三个月后你看着一堆「更新」，完全想不起来哪次是哪次。

好习惯：一句话说清楚做了什么，用动词开头。

# 好
git commit -m "产品页增加起订量字段"
git commit -m "修复移动端菜单不展开"
git commit -m "移除未使用的 jQuery 依赖"

# 不好
git commit -m "更新"
git commit -m "改了点东西"
git commit -m "asdf"

不用写长篇大论，一句话说清就行。

六、提交频率：小步快跑

不要攒一周的改动一次性提交。每完成一个小改动就提交一次。

好处：

• 出问题时能精确到「是这次改动引入的」
• 回退时只丢掉一小部分工作
• 提交信息能写得准确

一个判断标准：如果这次改动让你紧张（怕改坏），那就该先提交一次再继续。

七、可视化工具（不用记命令）

如果你不想记命令：装 GitHub Desktop（免费）或者用 VS Code 自带的 Git 面板。

基本操作都能用鼠标完成：看改动、勾选文件、写提交信息、点提交、看历史、回退。

命令行更适合批量和高级操作，图形工具更适合日常。两个都用也没问题。

八、几个真实的坑

坑 1：把 wp-config.php 提交了，还推到了公开仓库

这是最严重的事故。GitHub 上有机器人专门扫描新提交的配置文件，你的数据库密码可能在几分钟内被扫到，然后服务器被入侵。

预防：

• 提交前养成看 git status 的习惯，确认没有敏感文件
• 把 wp-config.php 写进 .gitignore
• 敏感配置用环境变量，不写在文件里

补救（如果已经提交了）：改掉数据库密码是第一优先级，然后从 Git 历史里清除（git filter-branch 或 BFG Repo-Cleaner），并且强制推送。但 assume 它已经泄露了，密码必须改。

坑 2：Git 不能当备份用

再强调一次：Git 只管代码。数据库里的文章、订单、产品数据，和 uploads 里的图片，都不在里面。

服务器整个没了，光有 Git 你恢复不出一个能用的网站。备份需要单独的方案。

坑 3：在服务器上直接 git pull 当部署

很多人图省事：本地改 → push → 服务器 git pull。这招能用，但有问题：

• 服务器上的临时修改会冲突
• 没有回滚机制（pull 之后发现有问题，得手动 reset）
• 数据库变更没法自动同步

小项目这么干没问题，但要知道它的局限。而且 pull 之后一定要去前台看一眼。

九、我的实际用法

给一个参考，不乱而有效：

1. 每个客户项目的主题单独一个仓库，推到私有仓库（GitHub 私有仓库免费，或者 Gitee）
2. 每次开始干活前先 git pull（防止在别的电脑上改过忘了同步）
3. 改一个小功能提交一次，信息写清楚
4. 每天结束前 push 一次——这就是异地备份
5. 大改动开分支，确认没问题再合回主分支

这套流程每天多花的时间：两三分钟。换来的是再也不怕改代码。

最后

学 Git 的最小成本路线：先学会 init / add / commit / checkout 这四个命令，用起来。其他的（分支、合并、rebase）等你真正需要的时候再学。

很多人卡在「想系统学完 Git 再用」，结果永远没用上。这四个命令就能让你获得 80% 的收益。

而对一个靠接单交付的人来说，「敢改代码」本身就是生产力——你不用再为了一次不确定的改动纠结半小时。