版本控制与 Git 工作流
一、版本控制的必要性
版本控制（Version Control）把代码的每次变更记录下来，形成可追溯的历史：谁在什么时候改了什么、为什么改（提交信息）。价值在于：可回溯——改坏了可以回到上一版；可对比——看某次提交具体改了哪些行；可协作——多人并行开发不同功能，通过分支与合并整合；可追溯——出问题时能定位引入问题的提交。
没有版本控制时，要么靠「复制文件夹」备份（容易乱、难合并），要么改同一文件互相覆盖。有了 Git 等工具，每个提交有唯一 ID，分支可以独立演进再合并，冲突由工具辅助解决，协作和发布都有章可循。
二、Git 基本概念：提交、分支、合并、变基
Git 是分布式版本控制系统：每人本地都有完整仓库，可离线提交，再与远程同步。提交（commit）是一次变更的快照，包含改动的文件内容、作者、时间、提交信息；每次提交有一个哈希 ID，形成一条历史链。分支（branch）是指向某次提交的指针，默认有 main（或 master）；新建分支即新指针，在分支上提交只移动该指针，不影响其他分支。合并（merge）把两个分支的改动合到一起，产生一次合并提交（或快进）；变基（rebase）把当前分支的提交「挪」到目标分支最新提交之后，历史呈一条线，但会改写提交历史，公共分支上慎用。
常用命令示例（理解即可，不必背）：
git add . && git commit -m "feat: add login"
git branch feature/order # 新建分支
git checkout feature/order # 切换分支（或 git switch）
git merge feature/order # 把 feature/order 合并进当前分支
git rebase main # 把当前分支变基到 main 最新提交后
三、分支策略：Git Flow、GitHub Flow、Trunk-Based
「怎么用分支」没有唯一答案，常见有三种策略，按团队规模和发布节奏选择。
develop 和 main；功能在 feature/* 开发，完成合并回 develop；发版时从 develop 拉 release/*，测试通过后合并到 main 并打 tag；线上修 bug 用 hotfix/* 从 main 拉出，修完合并回 main 和 develop。分支多、流程清晰，适合有固定发版周期、需要严格发布管理的项目。main（始终可部署）；功能在 feature/* 开发，通过 Pull Request（PR）合并进 main；没有 develop、release，发版即合并到 main 并部署。简单、适合持续交付、小团队或开源协作。四、协作与 Code Review 的衔接
版本控制不仅管代码，还管协作流程。典型做法：功能在分支开发，完成后不直接合并主分支，而是发起 Pull Request（PR） 或 Merge Request（MR）；他人审查代码、提意见，通过后再合并。这样主分支质量有保障、知识通过 Review 传递、问题在合并前暴露。
与 Git 工作流的衔接：小步提交——每个 commit 做一件事、信息写清，便于 Review 和回溯；分支命名约定——如 feature/订单页、fix/登录超时，一眼能看出用途；PR 描述——写清改了什么、为什么、如何测，方便审查；合并前更新——把主分支最新改动合并或变基到当前分支，减少冲突、保证合入后通过 CI。Code Review 关注逻辑、可读性、测试与边界情况，版本控制则保证「谁改了什么」可追溯、可回滚。
一句话： 版本控制记录每次变更、可回溯可协作；Git 用提交、分支、合并、变基管理历史与并行开发。分支策略常见有 Git Flow（多分支、develop/release）、GitHub Flow（单 main + PR）、Trunk-Based（主干为主、短分支或功能开关）。协作通过 PR/MR 与 Code Review 衔接，小步提交、清晰分支命名与 PR 描述能让流程更顺。
feat: 添加订单导出、fix: 修复登录超时，便于日后用 git log 和工具生成 Changelog。
五、小结
版本控制提供可追溯、可协作的变更历史；Git 通过提交、分支、合并、变基管理代码演进。分支策略：Git Flow 适合固定发版与多版本维护，GitHub Flow 适合持续交付与 PR 驱动，Trunk-Based 适合强 CI、小步提交。协作时用 PR/MR + Code Review 保证主分支质量并与 Git 工作流衔接。下一章讲代码规范、命名与可读性，把「怎么写容易读、容易维护」落到实处。