Git 工作流 + Code Review + 自动化部署方案 例子 FastAdmin 外包项目
适用场景：1-2人外包团队 | FastAdmin (PHP) | Linux + 宝塔面板
一、Git 初始化（从手动备份迁移到 Git）
1.1 安装 Git
Windows 上直接下载安装：https://git-scm.com/download/win
安装后打开 Git Bash，配置身份：
bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"1.2 把现有项目纳入 Git
在 Git Bash 中进入项目目录：
bash
cd /c/你的项目目录
# 初始化
git init
# 创建 .gitignore（非常重要！排除不需要版本管理的文件）
cat > .gitignore << 'EOF'
# FastAdmin 运行时文件
/runtime/*
!/runtime/.gitkeep
# 上传文件目录（大文件不走 Git，用 rsync 同步）
/public/uploads/*
# 宝塔/服务器配置
/.user.ini
/.htaccess_bak
# IDE 文件
.idea/
.vscode/
*.swp
# 系统文件
.DS_Store
Thumbs.db
# 手动备份文件（你们之前的版本管理方式）
*.日期.*
*.bak
*.backup
# Composer 依赖（可选，如果 vendor 不大可以提交）
# /vendor/
# 敏感配置（数据库密码等，建议用 .env 管理）
/application/database.php
/application/config.php
EOF
# 首次提交
git add .
git commit -m "init: 项目首次纳入 Git 版本管理"1.3 推送到远程仓库
推荐用 Gitee（国内快）或 GitHub：
bash
# 在 Gitee 上创建仓库后
git remote add origin https://gitee.com/你的用户名/你的项目名.git
git push -u origin main二、Git 工作流（适合小团队的极简方案）
2.1 分支策略
main (生产环境代码，永远可部署)
├── feature/xxx (开发新功能)
├── fix/xxx (修 Bug)
└── dev (可选：开发集成分支)1-2人团队推荐用最简单的两分支模型：
| 分支 | 用途 | 规则 |
|---|---|---|
main |
生产环境代码 | 不直接改，只通过合并进入 |
feature/功能名 |
开发新功能 | 开发完提 PR 合并回 main |
2.2 日常开发流程
bash
# 1. 开始新功能前，先拉最新代码
git checkout main
git pull
# 2. 创建功能分支
git checkout -b feature/用户管理优化
# 3. 开发过程中，随时提交
git add .
git commit -m "feat: 添加用户导出功能"
# 4. 功能开发完成，推送到远程
git push origin feature/用户管理优化
# 5. 在 Gitee/GitHub 上创建 Pull Request（这就是 Code Review 入口）
# 6. Review 通过后合并到 main
# 7. 删除功能分支
git branch -d feature/用户管理优化2.3 提交信息规范
bash
# 格式：类型: 简短描述
feat: 添加用户导出功能 # 新功能
fix: 修复登录页面样式错位 # Bug 修复
refactor: 重构订单查询逻辑 # 重构
docs: 更新部署文档 # 文档
style: 格式化代码 # 格式调整
chore: 升级 FastAdmin 版本 # 杂项三、Code Review 流程（1人也能做）
3.1 核心思路
即使只有你一个人，通过 PR 提交代码 + 自检清单 也比直接改 main 安全得多。
它让你在合并前"踩一脚刹车"，检查自己有没有遗漏。
3.2 操作步骤
1. 写完代码 → 推到 feature 分支 → 创建 PR（Pull Request）
2. 打开 PR 页面 → 对照自检清单逐项检查
3. 检查通过 → 自己点 Merge
4. 如果发现问题 → 在 PR 里修改，再检查3.3 PR 自检清单模板
在项目根目录创建 .github/pull_request_template.md：
markdown
## 变更说明
<!-- 简述这次改了什么、为什么改 -->
## 自检清单
- [ ] 功能是否按需求实现完整？
- [ ] 是否有未提交的调试代码（dd()、var_dump()、console.log）？
- [ ] 是否有硬编码的配置（数据库地址、密码、API Key）？
- [ ] 是否修改了数据库结构？是否有对应的 SQL 迁移脚本？
- [ ] 是否影响了现有功能？是否需要回归测试？
- [ ] 代码是否符合 PSR-2 编码规范？
- [ ] 敏感操作是否有权限校验？
- [ ] 前端是否有 XSS 风险？（用户输入是否转义）
## 测试
- [ ] 本地测试通过
- [ ] 测试环境验证通过（如适用）
## 数据库变更
<!-- 如有，附上 SQL 语句 -->
## 截图/录屏
<!-- 如有 UI 变更，附截图 -->3.4 配置 PR 模板
bash
# 在项目根目录创建
mkdir -p .github
cat > .github/pull_request_template.md << 'TEMPLATE'
## 变更说明
<!-- 简述这次改了什么、为什么改 -->
## 自检清单
- [ ] 功能是否按需求实现完整？
- [ ] 是否有未提交的调试代码（dd()、var_dump()、console.log）？
- [ ] 是否有硬编码的配置（数据库地址、密码、API Key）？
- [ ] 是否修改了数据库结构？是否有对应的 SQL 迁移脚本？
- [ ] 是否影响了现有功能？是否需要回归测试？
- [ ] 代码是否符合 PSR-2 编码规范？
- [ ] 敏感操作是否有权限校验？
- [ ] 前端是否有 XSS 风险？（用户输入是否转义）
## 测试
- [ ] 本地测试通过
- [ ] 测试环境验证通过（如适用）
## 数据库变更
<!-- 如有，附上 SQL 语句 -->
## 截图/录屏
<!-- 如有 UI 变更，附截图 -->
TEMPLATE
git add .github/
git commit -m "chore: 添加 PR 自检清单模板"四、自动化部署（Git Push → 宝塔自动同步）
方案 A：宝塔 WebHook（推荐，最简单）
4.1 宝塔端配置
- 宝塔面板 → 软件商店 → 安装「宝塔WebHook」
- 添加 Hook，名称如
deploy-fastadmin - 脚本内容：
bash
#!/bin/bash
# 项目路径
PROJECT_PATH="/www/wwwroot/你的项目目录"
# 拉取最新代码
cd $PROJECT_PATH
git pull origin main
# 清除 FastAdmin 缓存
php think clear
# 如有 Composer 依赖变更
# composer install --no-dev --optimize-autoloader
# 如有数据库迁移
# php think migrate:run
echo "部署完成: $(date)"- 保存后获取 WebHook URL（类似
http://你的服务器:8888/hook?access_key=xxx）
4.2 Git 端配置（Gitee）
Gitee 仓库 → 管理 → WebHooks → 添加：
- URL：填上面的 WebHook URL
- 密码：留空或填宝塔生成的
- 触发：选择 Push
→ 之后每次 git push 到 main，服务器自动拉取部署！
方案 B：rsync 手动/半自动部署
适合不想在服务器装 Git 的情况：
bash
# Windows 上安装 rsync（通过 cwRsync 或 WSL）
# 然后本地构建后直接同步到服务器
# 基本命令
rsync -avz --delete \
--exclude='.git/' \
--exclude='runtime/' \
--exclude='.env' \
/c/你的项目目录/ \
root@你的服务器IP:/www/wwwroot/你的项目目录/
# 常用参数说明：
# -a 归档模式（保留权限、时间等）
# -v 显示详情
# -z 压缩传输
# --delete 删除服务器上本地没有的文件（谨慎使用）
# --exclude 排除不需要同步的文件方案对比
| 宝塔 WebHook | rsync | |
|---|---|---|
| 部署方式 | Git Push 自动触发 | 手动执行命令 |
| 服务器需要 Git | ✅ 是 | ❌ 不需要 |
| 安全性 | 更安全（只拉取） | --delete 有风险 |
| 推荐度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
五、敏感配置管理
FastAdmin 的 database.php 和 config.php 包含数据库密码，不应纳入 Git：
5.1 创建配置模板
bash
# 复制一份作为模板
cp application/database.php application/database.php.exampledatabase.php.example 中的密码改为占位符：
php
'hostname' => env('DB_HOST', '127.0.0.1'),
'database' => env('DB_NAME', 'fastadmin'),
'username' => env('DB_USER', 'root'),
'password' => env('DB_PASS', ''),5.2 .gitignore 中排除真实配置
/application/database.php
/application/config.php5.3 服务器上首次部署时
bash
cp application/database.php.example application/database.php
# 然后手动填入真实的数据库信息六、执行路线图
第1周：Git 初始化
├── 安装 Git，配置 .gitignore
├── 现有代码首次 commit + push
└── 熟悉基本 Git 操作（commit / branch / merge）
第2周：工作流落地
├── 开始用 feature 分支开发
├── 创建 PR 自检清单模板
└── 养成"先建分支再开发"的习惯
第3周：自动化部署
├── 宝塔安装 WebHook 插件
├── 配置 Git Push 自动部署
└── 测试完整流程：本地改代码 → push → 服务器自动更新
第4周：优化
├── 敏感配置从 Git 中分离
├── 引入 PHP CodeSniffer 检查代码规范
└── 沉淀团队开发规范文档PR 自检清单 · 团队使用指南
目录结构
├── .github/
│ ├── pull_request_template.md ← GitHub PR 描述模板（会自动填充到每个 PR）
│ └── workflows/
│ └── phpcs.yml ← GitHub Actions 自动检查（PHP CodeSniffer）
├── .gitlab/
│ └── merge_request_template.md ← GitLab MR 描述模板
└── phpcs.xml.dist ← PHP CodeSniffer 配置快速上手（5 分钟）
Step 1：安装 CodeSniffer（本地自检用）
bash
composer require --dev squizlabs/php_codesnifferStep 2：本地自检（创建 PR 前必跑）
bash
# 检查并显示详细错误
./vendor/bin/phpcs --standard=phpcs.xml.dist
# 自动修复可修复的格式问题（缩进、引号等）
./vendor/bin/phpcs --standard=phpcs.xml.dist --fixStep 3：推送到远程，PR 自检清单会自动出现
推送后创建 PR，GitHub 会自动：
- 在 PR 描述中展示清单模板
- 自动运行 CI 检查 CodeSniffer，阻断不合规的 PR
GitHub 模板自动生效的条件
确保仓库根目录有 .github/ 文件夹，且包含 pull_request_template.md。
GitLab 则在项目 Settings → General → Merge request templates 中选择对应路径。
团队落地建议
| 阶段 | 目标 | 建议 |
|---|---|---|
| 第 1 个月 | 养成习惯 | 不强制，review 时提醒补清单 |
| 第 2 个月 | 严格执行 | CI phpcs 阻断 + 清单必填 |
| 第 3 个月+ | 持续优化 | 根据积累的问题迭代清单内容 |
常见问题
Q：本地 phpcs 有警告但不好改，怎么办？
A：可以在 phpcs.xml.dist 中临时在 <exclude-pattern> 添加文件路径，或在文件顶部加 @phpcs:disable 注释，按需使用。
Q：清单太长，能否精简？
A：可以。根据团队痛点优先保留前 3 个维度（功能 / 规范 / 安全），其他逐步增加。
Q：CI 没跑起来？
A：检查仓库 Settings → Actions → Workflow permissions 是否允许 GitHub Actions 运行。