4、版本控制入门：Git与GitHub/GitLab基础，分支管理策略（Git Flow），团队协作工作流
版本控制这件事，说白了就是给你的代码装上一台「时光机」。我刚开始写代码那会儿，项目文件夹里全是「最终版」「最终版2」「打死不改版」……现在想想，真是惨不忍睹。有了 Git，这一切都变得清爽了。
4.1 为什么需要版本控制？
你想想看，一个项目少则几百个文件，多则成千上万。如果没有版本控制，你怎么知道昨天改了哪里？怎么把同事搞坏的代码恢复回来？怎么同时开发多个功能而不互相干扰？
版本控制的核心价值就三点：
- 记录历史：每一次提交都是一次快照，随时可以回退
- 协同工作：多人同时开发，互不干扰
- 分支管理：并行开发不同功能，最后合并
核心概念：Git 是分布式版本控制系统，每个开发者本地都有完整的代码仓库。不像 SVN 那种中央集权式的，Git 更灵活，也更安全。
4.2 Git 基础操作
我记得第一次用 Git 时，被那些命令搞得晕头转向。其实常用的就那么几个，掌握了就能应付 90% 的场景。
4.2.1 初始化与配置
# 安装后先配置身份
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
# 初始化一个新仓库
git init
# 克隆一个远程仓库
git clone https://github.com/用户名/仓库名.git我的习惯：配置时我会加上 --global，这样所有项目都共用一套配置。如果你在不同项目用不同身份，可以去掉 --global，在每个项目里单独配置。
4.2.2 日常操作三板斧
开发过程中，你基本就在这三个命令之间循环：
# 查看当前状态
git status
# 把文件加入暂存区
git add 文件名 # 添加单个文件
git add . # 添加所有改动
# 提交到本地仓库
git commit -m "feat: 添加用户登录功能"为什么会分 add 和 commit 两步？嗯，这里要注意：add 是把改动「打包」到暂存区，commit 才是真正生成一个历史版本。你可以先 add 几个文件，再仔细检查一遍，确认无误后再 commit。
4.2.3 远程仓库同步
# 推送本地代码到远程
git push origin main
# 拉取远程最新代码
git pull origin main
# 查看远程仓库信息
git remote -v我曾经踩过的坑：有一次我直接 git push 了还没测试完的代码，结果同事拉下来后项目直接跑不起来。从那以后，我养成了推送前先 git status 确认的习惯，确保没有遗漏未提交的文件。
4.3 GitHub 与 GitLab 基础
Git 是本地工具，GitHub 和 GitLab 是远程托管平台。说白了，就是给你的代码找个「云上仓库」。
| 特性 | GitHub | GitLab |
|---|---|---|
| 定位 | 开源社区为主 | 企业级 DevOps 平台 |
| 私有仓库 | 免费版有限制 | 免费版无限制 |
| CI/CD | GitHub Actions | 内置 CI/CD |
| 自托管 | 不支持 | 支持 |
我个人习惯用 GitHub 做开源项目，公司内部则用 GitLab。GitLab 的自托管功能很实用，代码不用出公司内网，安全性更高。
4.4 分支管理策略：Git Flow
分支管理，是团队协作的核心。没有分支策略，大家在一个分支上乱改，那画面太美我不敢看。
Git Flow 是最经典的分支模型，它定义了五种分支：
- main：主分支，只存放稳定版本
- develop：开发分支，日常开发的主线
- feature：功能分支，从 develop 拉出，开发完合并回去
- release：发布分支，从 develop 拉出，用于测试和修复
- hotfix：紧急修复分支，从 main 拉出，修复完合并回 main 和 develop
核心原则：永远不要在 main 上直接开发。main 只接受来自 release 或 hotfix 的合并。这样能保证 main 始终是可部署的稳定版本。
4.4.1 实际工作流示例
# 1. 从 develop 拉出功能分支
git checkout develop
git checkout -b feature/user-login
# 2. 开发完成后合并回 develop
git checkout develop
git merge --no-ff feature/user-login
# 3. 准备发布时，从 develop 拉出 release 分支
git checkout -b release/v1.0.0
# 4. 测试修复后，合并到 main 和 develop
git checkout main
git merge --no-ff release/v1.0.0
git tag v1.0.0
git checkout develop
git merge --no-ff release/v1.0.0我的建议：--no-ff 参数很重要，它会强制创建一个合并提交，保留分支的历史信息。这样以后查问题，一眼就能看出这个功能是从哪个分支合并来的。
4.5 团队协作工作流
光有分支策略还不够，团队协作还需要一套规范的工作流。我参与过的项目里，最常用的是 Fork 工作流和 Feature Branch 工作流。
4.5.1 Feature Branch 工作流
这是中小团队最常用的方式：
- 从 develop 拉出 feature 分支
- 在 feature 分支上开发
- 提交 Pull Request（PR）
- 代码审查通过后合并
- 删除 feature 分支
4.5.2 代码审查规范
代码审查不是走过场，我见过太多团队因为审查不严，把 bug 带到了线上。这里分享几个要点：
- PR 要小：一个 PR 只做一件事，改动不超过 200 行
- 描述要清晰：写清楚改了啥、为什么改、怎么测试
- 审查要仔细：不只是看逻辑，还要看命名、注释、异常处理
- 及时响应：PR 挂太久，容易产生冲突
我曾经犯过的错：有一次我提交了一个 500 行的 PR，同事看了半小时都没看完，最后直接点了通过。结果上线后出了严重的性能问题。从那以后，我坚持「小 PR、勤提交」的原则，每个 PR 控制在 100 行以内。
4.6 避坑指南
最后，分享几个我这些年踩过的坑，希望能帮你少走弯路：
- 不要直接 push 到 main：哪怕你是项目负责人，也走 PR 流程
- 提交信息要规范：推荐用 Conventional Commits 规范，比如
feat:、fix:、chore: - 定期拉取最新代码：避免长时间不更新，最后冲突一大堆
- 不要提交敏感信息：密码、密钥、token 这些，用环境变量或配置文件管理
- 学会使用 .gitignore：把 node_modules、.env、dist 等目录排除掉
版本控制这东西，刚开始觉得麻烦，用顺手了就会发现——没有它，你根本没法做项目。尤其是团队协作，一套好的 Git 工作流，能让效率翻倍。嗯，今天就先聊到这儿，下一章我们开始实战，用 Git 管理一个真实的前端项目。