工程化与协作：Git 工作流、CI/CD、代码审查、环境管理
Git 工作流、分支策略、提交规范、CI/CD 自动化、代码审查、环境管理、Monorepo，这些是现代软件开发的工程化实践，学会用它们让开发过程可重复、可追溯、可协作
- 就看这俩事儿：Git 的核心概念、常用命令，还有分支策略——Git Flow、GitHub Flow、Trunk Based。
- 学会写规范的提交信息（Conventional Commits），理解提交历史的价值
- 掌握 CI/CD 的核心概念和主流工具（GitHub Actions / GitLab CI / Vercel / 云效），学会配置自动化流水线
- 理解代码审查（Code Review）的价值和最佳实践，学会做有效的审查和接受审查
- 就盯俩事儿：环境管理，管开发、测试、预发、生产这几个环境；配置管理，管环境变量、密钥管理、配置即代码。
- 了解 Monorepo 的概念、工具（pnpm workspace / Turborepo / Nx）和适用场景
- 学会用 AI 辅助工程化：AI 生成提交信息、审查代码、写 CI 配置、写文档
为什么需要工程化
一个人写代码可以随便写、随便改、直接上线。但项目变大、团队变多、上线变频繁，没工程化就乱了：代码丢了，改A坏B，上线手动操作半小时，出问题不知道谁改的，回滚要半天。工程化就是让开发过程可重复、可追溯、可协作、可自动化的一套实践。它不是束缚，是让你更快、更稳交付的东西。
工程化的核心目标
可追溯：每一行代码都知道谁改的、为什么改、什么时候改的（Git）可重复：任何人、任何时候都能从源码构建出相同的产物（构建脚本+依赖锁定）可协作：多人同时开发不冲突，代码质量有保障（分支+代码审查）可自动化：测试、构建、部署自动化，减少人工操作和人为错误（CI/CD）可回滚：出了问题能快速回滚到上一个稳定版本（版本管理+蓝绿/灰度发布）可观测：线上出了问题能快速定位（日志+监控+告警）工程化=让开发过程可追溯/可重复/可协作/可自动化/可回滚/可观测
Git：版本控制的基石
Git 是主流的分布式版本控制系统，几乎所有软件开发都用它。核心概念：仓库（Repository）：代码的家，包含所有文件和历史；提交（Commit）：代码的一个快照，有唯一 ID（hash）、作者、时间、说明；分支（Branch）：代码的一条独立开发线，默认是 main/master；合并（Merge）：把一个分支的改动合并到另一个分支；远程（Remote）：代码托管在 GitHub/GitLab/Gitee 上的远程仓库。
# Git 常用命令速查
# 配置
# git config --global user.name "Your Name"
# git config --global user.email "you@example.com"
#
# 基础
# git init # 初始化仓库
# git clone <url> # 克隆远程仓库
# git status # 查看当前状态
# git add <file> # 把文件加入暂存区（git add . 加所有）
# git commit -m "message" # 提交
# git push # 推送到远程
# git pull # 从远程拉取
#
# 分支
# git branch # 查看分支
# git branch <name> # 创建分支
# git checkout <name> # 切换分支（或 git switch <name>）
# git checkout -b <name> # 创建并切换分支
# git merge <name> # 合并分支到当前分支
# git branch -d <name> # 删除分支
#
# 历史与回退
# git log --oneline # 查看提交历史（简洁版）
# git diff # 查看未暂存的改动
# git reset --hard <commit> # 回退到某个提交（危险，会丢改动）
# git revert <commit> # 新建一个提交来撤销某个提交（安全，推荐）
#
# 储藏（临时保存改动）
# git stash # 临时保存当前改动
# git stash pop # 恢复最近储藏的改动提交规范：Conventional Commits
提交信息别瞎写。规范的提交信息能让历史可读，能自动生成 changelog，能触发自动化。Conventional Commits 是最流行的提交规范，格式：<type>(<scope>): <subject>。type 包括：feat（新功能）、fix（修复 bug）、docs（文档）、style（格式，不影响代码逻辑）、refactor（重构）、perf（性能优化）、test（测试）、chore（构建/工具/依赖）、ci（CI/CD 配置）。
Conventional Commits 示例feat(auth): 添加微信登录功能fix(course): 修复课程进度保存失败的问题docs(readme): 更新安装说明style(ui): 统一按钮圆角为 8pxrefactor(api): 重构用户接口，提取公共逻辑perf(list): 优化课程列表加载速度，加入虚拟滚动test(auth): 添加登录接口的单元测试chore(deps): 升级 react 到 18.3ci(github): 添加自动部署流水线 好的提交信息：用动词开头（添加/修复/优化/重构）简洁明了，不超过 50 字说明「做了什么」和「为什么」，不是「怎么做到的」一个提交只做一件事（不要把不相关的改动放在一个提交里） 差的提交信息："更新" "修改" "fix" "asdf"（不知道改了什么）"修复了一些问题"（哪些问题？）一个提交里改了 10 个文件，包含 3 个不相关的功能
写完代码后，用 AI 生成提交信息就行：把 git diff 的内容给 AI，让它按 Conventional Commits 规范生成。GitHub Copilot、GitLens、Cline 这些 IDE 插件都内置了这个功能，一键就能生成规范的提交信息。AI 生成的提交信息要审查，确保它准确描述了你的改动，AI 可能误解你的意图或遗漏重要改动。
分支策略：多人协作的规则
一个人开发能直接在 main 上提交，多人协作得用分支策略——什么时候建分支、分支怎么命名、什么时候合并、合并后怎么处理。三种主流策略：
小团队（<5人）、Web应用、持续部署 → GitHub Flow，简单高效，别搞复杂的Git Flow；有版本发布周期、要维护多个版本（比如App要维护v1.x和v2.x）→ Git Flow；高绩效团队、CI完善、追求速度 → Trunk Based + feature flag；一个人开发 → 直接在main上提交就行，不需要分支策略（但要勤提交、写好提交信息）；本课程的朋友好学 App是一个人开发，直接在main上提交，勤提交+规范提交信息就够了，不需要复杂的分支策略。分支策略是为协作服务的，别为了「规范」搞复杂，适合团队规模和发布模式就行。
CI/CD：自动化的核心
CI（Continuous Integration，持续集成）：每次提交代码后，自动运行测试、构建、代码检查，确保改动没破坏现有功能。CD（Continuous Delivery/Deployment，持续交付/部署）：CI 通过后，自动把构建产物部署到测试/预发/生产环境。CI/CD 的价值：减少人工操作（不用手动跑测试、打包、部署）；快速发现问题（提交后几分钟内就知道有没有破坏功能）；部署可重复可回滚（任何人都能触发部署，出问题能快速回滚）；提高发布频率（从「每月发版」到「每天发版」甚至「每小时发版」）。
# GitHub Actions 示例：一个简单的 CI/CD 流水线
# .github/workflows/ci.yml
# name: CI/CD
# on:
# push:
# branches: [main]
# pull_request:
# branches: [main]
#
# jobs:
# test:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - uses: actions/setup-node@v4
# with:
# node-version: '20'
# cache: 'npm'
# - run: npm ci
# - run: npm run lint
# - run: npm run test
# - run: npm run build
#
# deploy:
# needs: test
# if: github.ref == 'refs/heads/main'
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - uses: actions/setup-node@v4
# with:
# node-version: '20'
# - run: npm ci
# - run: npm run build
# - name: Deploy to Vercel
# run: npx vercel --prod --token=$VERCEL_TOKEN
# env:
# VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
#
# 这个流水线：
# 1. 每次 push/PR 到 main，自动跑 lint+test+build
# 2. main 分支且测试通过后，自动部署到 Vercel
# 3. 密钥（VERCEL_TOKEN）存在 GitHub Secrets，不写在代码里GitHub Actions：和 GitHub 深度集成，配置简单，免费额度够用，开源项目免费，最流行（本示例用的就是）；GitLab CI：GitLab 自带，功能强大，适合用 GitLab 的团队；Vercel/Netlify：前端项目专用，push 到 main 自动部署，零配置，最简单（静态站/Next.js/Nuxt 首选）；云效/CODING/Jenkins：国内企业常用，支持私有化部署；Docker + 自建：完全可控，但运维成本高。选择：前端项目 → Vercel/Netlify（零配置）；全栈/复杂项目 → GitHub Actions（灵活）；企业/私有化 → GitLab CI/Jenkins。本课程的朋友好学 App 是静态导出+Node 后端，前端可以部署到 Vercel/Netlify，后端部署到 Railway/云服务器，用 GitHub Actions 做 CI。
代码审查（Code Review）
代码审查是代码合并前，让另一个开发者看一遍的实践。就这几个用处：发现作者自己看不到的Bug；保证代码风格一致、可维护、有测试；审查者能学到新东西，作者能得到反馈；代码是团队的，不是个人的，能达成共识。
AI 可以作为代码审查的助手：提交 PR 前，用 AI 审查自己的代码（把 diff 给 AI，让它找 Bug、安全问题、性能问题、可改进点）；GitHub 上有 AI Code Review 工具（如 CodeRabbit、GitHub Copilot Code Review、Cline），自动在 PR 上评论；AI 审查不能替代人工审查——AI 能找到明显的 Bug 和安全问题，但业务逻辑的正确性、架构合理性、团队约定需要人来判断。最佳实践：AI 先审（找明显问题）→ 人再审（业务逻辑和架构），两层叠加。
环境管理与配置管理
软件有多个环境：开发（dev，本地开发用）、测试（test/staging，QA测试用）、预发（pre-prod，和生产一样配置，上线前最后验证）、生产（prod，真实用户用）。每个环境的配置（数据库地址、API Key、第三方密钥）不同，不能写死在代码里。配置管理的核心原则：
# 环境管理最佳实践
# 1. 配置和代码分离：配置存在环境变量或配置文件里，不写死在代码中
# 2. .env 文件：本地开发用 .env 文件存配置，加入 .gitignore（不进版本控制）
# 3. .env.example：提交一个 .env.example 模板（只有 key 没有 value），告诉团队需要哪些配置
# 4. 生产环境配置：存在部署平台的环境变量管理（Vercel Environment Variables、Railway Variables、云服务器的 /etc/environment）或密钥管理服务（AWS Secrets Manager、阿里云 KMS、HashiCorp Vault）
# 5. 密钥不进 Git：API Key、数据库密码、JWT Secret 绝对不能提交到 Git（一旦提交，即使删了也在历史里，必须吊销换新）
# 6. 配置即代码：复杂配置用代码管理（如 Terraform 管理云资源、docker-compose 管理本地环境），可版本控制、可重复
# 7. 不同环境隔离：开发环境不能连生产数据库，测试数据不能污染生产
#
# .gitignore 示例：
# .env
# .env.local
# node_modules/
# dist/
# build/
# *.log
# .DS_Store
#
# .env.example 示例：
# # 数据库配置
# DATABASE_URL=postgresql://user:password@localhost:5432/mydb
# # API 配置
# API_KEY=your_api_key_here
# JWT_SECRET=your_jwt_secret_here
# # 应用配置
# NODE_ENV=development
# PORT=3000如果不小心把 API Key/密码提交到了 Git：立即吊销/轮换那个密钥（在服务商后台生成新的，旧的作废）——这是最关键的一步，因为密钥已经在 Git 历史里，任何人都能看到；从代码里删除密钥，改用环境变量；用 git filter-repo 或 BFG Repo-Cleaner 清理 Git 历史，但如果已经推到公开仓库，清理历史也没用，因为别人可能已经 fork/缓存了，所以第一步吊销最重要；加 .gitignore 防止再次提交；用 git secrets / truffleHog / gitleaks 等工具扫描历史，确认没有其他泄露；如果是生产数据库密码，还要检查数据库有没有被异常访问。本课程的朋友好学 App 前端不保存任何 AI 密钥，火山方舟密钥只放在后端 server.js 同目录的 ai.config.json（或环境变量 ARK_API_KEY），/admin 管理平台写入的 admin.config.json 也一并加入 .gitignore，绝不入库、绝不下发到安装包。
Monorepo：一个仓库管理多个项目
Monorepo（Monolithic Repository）是把多个相关项目放在一个 Git 仓库里管理，不是每个项目一个仓库。例如：一个公司的前端 App、后端 API、共享组件库、文档都在一个仓库里。优势：代码共享方便（共享库直接引用，不需要发 npm 包）；原子提交（改一个功能，前端后端一起改，一个提交搞定）；统一工具链（一个 lint/test/build 配置管所有项目）；依赖版本统一。劣势：仓库变大（clone 慢、历史长）；权限管理粗（不能只给某个人某个子目录的权限）；CI 可能变慢（改一个文件要跑所有项目的测试，需要增量构建）。工具：pnpm workspace（最简单）、Turborepo（增量构建+缓存）、Nx（功能最全，适合大团队）、Lerna（老牌，现在用 pnpm + Turborepo 更多）。
适合：多个项目共享大量代码（如组件库、工具函数、类型定义）；一个功能需要同时改前端和后端（原子提交）；小团队（<20人）管理多个相关项目；统一工具链和规范。不适合：项目之间完全无关（如一个电商网站和一个游戏，放一起没意义）；大团队需要细粒度权限控制（Monorepo 权限管理不如多仓库灵活）；项目有完全不同的技术栈和发布周期（强行放一起增加复杂度）。本课程的朋友好学 App 是单项目（前端+后端+Android 工程都在一个目录里，已经是事实上的 Monorepo 结构），不需要额外引入 Monorepo 工具。如果以后拆出独立的共享库或多个 App，再考虑 pnpm workspace + Turborepo。
本节小结
工程化核心目标：可追溯、可重复、可协作、可自动化、可回滚、可观测。Git 是版本控制基石，掌握常用命令；提交用 Conventional Commits 规范（feat/fix/docs/refactor/perf/test/chore），一个提交一件事，可用 AI 生成但要审查。分支策略：小团队 Web 应用用 GitHub Flow（最简单），有版本周期用 Git Flow，高绩效团队用 Trunk Based，一个人直接 main 提交。CI/CD 自动化：每次提交自动跑 lint/test/build，通过后自动部署；工具选 GitHub Actions（灵活）或 Vercel/Netlify（前端零配置）。代码审查：小 PR（<400行）、清晰描述、自动化先行、审查重点是正确性/安全/可维护/性能（格式让工具管）、建设性反馈、24小时响应、作者当学习机会；可用 AI 做审查助手但不能替代人工。环境管理：配置和代码分离、.env 本地+ .env.example 模板、生产配置存环境变量/密钥管理服务、密钥绝对不进 Git、泄露了立即吊销轮换。Monorepo：适合多项目共享代码/原子提交/小团队，工具 pnpm workspace+Turborepo，不适合无关项目/大团队细权限。接下来讲测试与质量——工程化做到位了，怎么保证代码质量。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
独立开发者选栈的第一标准是“能不能一个人最快稳定交付”，而不是哪个框架最新。Next.js 这类全栈框架把路由、构建、静态导出、服务端接口收敛到一套工具链里，配合静态导出 + WebView 原生壳，能让一个人同时覆盖 Web 与移动端；选型时先验证最不确定的环节（离线运行、原生能力、AI 流式），跑通原型再全面投入，避免做到一半发现关键能力不成立。