网站开发的 Git 工作流：从单人项目到团队协作的最佳实践

一位独立开发者维护个人博客三年，中间有一次改坏样式、还覆盖了旧的备份，最后是靠一条几个月前的 commit 把网站恢复原样——他后来常说，「Git 最大的价值不是记录，是后悔药」。对网站开发来说，Git 从第一行代码就该在场：单人项目要「能回滚」，团队项目要「能协作」。本文从单人到团队，给出一套够用又不臃肿的工作流。

一、单人项目：GitHub Flow 就够

对个人网站、个人博客或小工具，别上复杂的流程，GitHub Flow 是唯一推荐：一个 main 分支 + 若干短命功能分支。

# 1. 创建功能分支
git checkout -b feature/new-homepage

# 2. 在分支上开发，频繁提交
git add .
git commit -m "feat: redesign homepage hero section"

# 3. 提交到远程
git push origin feature/new-homepage

# 4. 在 GitHub 上创建 Pull Request
# 5. 自我审查后合并到 main
git checkout main
git merge feature/new-homepage

关键习惯是每次提交只做一个逻辑变更：改样式和改文案分开提交，回滚时才能精确到「只撤销样式那次」。单人开发最容易偷懒，但半年后再看 git log，干净的提交历史能帮你省下大量排查时间。再补一个单人常用技巧：本地分支别攒太久，一个功能做完了就合并进 main 并删掉旧分支，分支越少，心里越有数。

提交信息规范

用 Conventional Commits 让历史可读、可自动化（不少发布工具直接按前缀生成 changelog）：

feat: 新增功能
fix: 修复 bug
docs: 文档变更
style: 代码格式（不影响功能）
refactor: 代码重构
perf: 性能优化
test: 测试相关
chore: 构建过程或辅助工具变更

示例：

feat: add user login page
fix: correct mobile menu z-index issue
perf: optimize image loading with lazy loading

二、团队协作：按发布节奏选流程

Git Flow（适合按版本发布的项目）

main ────────●─────────────●─────────  (稳定发布版本)
             \             /
develop ──────●───●──●──────●───  (日常开发分支)
                 \    /        \
feature/login    ●──●           feature/payment

分支命名规范

feature/xxx    — 新功能
fix/xxx        — Bug 修复
hotfix/xxx     — 紧急修复（直接合并到 main）
release/xxx    — 发布准备

取舍建议：持续部署的 SaaS 用 GitHub Flow，按版本交付的产品用 Git Flow。前者追求「小步快跑」，后者适合需要固定发布窗口（如 App Store 审核）的场景。人少时别照搬全套 Git Flow，develop 分支对 3 人团队往往是负担。补充一个细节：无论哪种流程，都要约定「谁有权合并到受保护分支」，并把这条写进团队约定，避免出现权限真空。

三、.gitignore：从源头拦住脏文件

# Node
node_modules/
npm-debug.log*
.env

# Build output
dist/
build/
.next/

# IDE
.vscode/
.idea/
*.swp
*.swo

# OS
.DS_Store
Thumbs.db

.env 这类含密钥的文件尤其重要：一旦提交进 Git 历史，删掉也无济于事（历史里还在）。真发生了，要用 git filter-repo 重写历史并轮换密钥。另外，.gitignore 本身也要纳入版本管理，团队才能在同一个页面上同步忽略规则。

四、CI/CD：让部署自动化

GitHub Actions 示例

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build
      
      - name: Deploy to server
        uses: easingthemes/ssh-deploy@main
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SOURCE: "dist/"
          REMOTE_HOST: ${{ secrets.DEPLOY_HOST }}
          REMOTE_USER: ${{ secrets.DEPLOY_USER }}
          TARGET: /var/www/example.com/

CI/CD 的收益是「把重复劳动交给机器」：每次 push 自动跑测试和构建，只有全绿才部署。密钥走仓库的 Secrets，千万别写进 yaml。如果项目还没有任何自动化，先别追求完整流水线，把「push 到 main 后自动构建并跑测试」这一条配上，收益最大。

五、最佳实践清单

频繁提交，尽早提交 — 每次提交聚焦一个逻辑变更；
写有意义的提交信息 — 让队友和未来的你能看懂意图；
不要直接 push 到 main — 分支 + PR/MR，配合分支保护规则（禁止强制推送、要求 PR 通过）；
在 PR 里描述变更 — 背景、改动、测试方式，缺一不可；
保持分支生命周期短 — 分支活得越久，合并冲突越多；
Code Review — 哪怕单人项目，PR 自审也能抓到低级错误，还能借助 AI 审查工具提速。

六、常见事故与应对

几个高频翻车现场和对应的救法：

提交错了文件：还没 push 就用 git reset --soft HEAD~1 撤销提交但保留改动；已经 push 了就用 git revert <commit> 生成一条反向提交，别用强制推送改写公共历史；
merge 冲突：优先用 git merge --abort 回到冲突前的干净状态，看清楚两侧改动再重试，别在冲突里硬凑；
误删分支：用 git reflog 找回分支指针——只要近期有过提交，分支基本都能捞回来；
误提交密钥：git filter-repo 重写历史 + 立即轮换密钥，双管齐下。

给团队的一个建议：定期演练一次「从生产事故回滚」。真到出事那天，手忙脚乱最容易再犯错；演练过的流程能让你在两分钟内完成回滚而不是半小时。

16IDC 观察

对网站项目，Git 的价值集中在「历史追溯」和「安全回滚」两点。就算你只是唯一开发者，从第一个文件开始 git init，几个月后你会感谢当初的自己。而一旦团队超过两个人，分支保护和 PR 审查就应该立刻开启，这是用最小成本守住代码质量底线的方式。更多建站技术实践可参考建站技术分类。

参考：Git 官方文档 https://git-scm.com/doc；Conventional Commits 规范 https://www.conventionalcommits.org/zh-hans/

网站开发的 Git 工作流：从单人项目到团队协作的最佳实践