版本控制基础：Git核心概念、Git工作流程、常用Git命令、分支策略
大家好，我是你们这门课的老朋友。今天咱们聊聊版本控制，说白了就是Git。嗯，这玩意儿是DevOps流水线的地基，地基不稳，上面盖啥都白搭。我见过太多团队，流水线跑得飞起，结果一查代码版本乱成一锅粥，最后全得回滚重来。所以，这一章咱们把Git的底裤都扒干净。
Git核心概念：你脑子里得有个模型
Git这东西，核心就三个区：工作区、暂存区、本地仓库。很多人用了好几年Git，其实没搞明白这三个区的关系。我刚开始带团队时，有个同事天天git add完就git commit，结果想撤销某个文件改动时，一脸懵。为啥？因为他脑子里没有这个模型。
- 工作区：你电脑上能看到的文件目录。你改代码，改的就是这里。
- 暂存区：一个临时存放区。你git add之后，改动就进了这里。说白了，就是「我准备提交这些文件了」的标记区。
- 本地仓库：git commit之后，改动才真正被记录到历史里。这里存着所有版本快照。
还有一个概念叫HEAD，它指向你当前所在的提交。我习惯把HEAD想象成一个「当前视角指针」。你切换分支，HEAD就跟着移动。你回滚版本，HEAD也动。嗯，记住这个，后面讲reset和rebase时你会感谢我。
核心要点：Git不是存差异，而是存快照。每次commit，Git都会拍一张所有文件的「照片」。所以Git仓库会越来越大，但好处是切换分支、回滚版本快得飞起。
Git工作流程：日常怎么玩
一个标准的Git工作流，其实就这几步。我每天上班第一件事就是git pull，确保本地是最新的。你想想看，要是你改了半天，最后发现别人已经改了同一个文件，那冲突解决起来多痛苦。
- git pull：拉取远程最新代码。我建议你养成习惯，改代码前先拉一次。
- git checkout -b feature/xxx：创建并切换到新分支。别在主分支上直接改，这是铁律。
- 修改代码：在工作区里干活。
- git add .：把改动加到暂存区。注意，这个点代表当前目录所有文件，你也可以指定具体文件。
- git commit -m "feat: 添加用户登录功能"：提交到本地仓库。提交信息要写清楚，别写「fix bug」这种废话。
- git push origin feature/xxx：推送到远程仓库。
- 创建Pull Request：在GitLab/GitHub上发起合并请求。等代码审查通过后，合并到主分支。
我曾经遇到过一个项目，团队里有人从来不写commit信息，全是「update」「fix」。后来线上出了bug，要回滚到某个版本，根本不知道哪个commit是干啥的。嗯，从那以后我定了个规矩：commit信息必须遵循Conventional Commits规范。
常用Git命令：这些你得背下来
Git命令很多，但日常用的就那几个。我列个表，你照着练就行。
| 命令 | 作用 | 我的经验 |
|---|---|---|
git init |
初始化一个Git仓库 | 新项目第一步，别忘加.gitignore |
git clone <url> |
克隆远程仓库到本地 | 我习惯加--depth=1，只拉最新版本，省时间 |
git status |
查看当前工作区状态 | 改代码前跑一下，心里有数 |
git log --oneline --graph |
查看提交历史（简洁版） | 我每天至少看一次，了解团队进度 |
git diff |
查看工作区与暂存区的差异 | commit前跑一下，确认没改错东西 |
git reset --hard HEAD~1 |
撤销最近一次提交 | ⚠️ 慎用！会丢失改动。我一般用git revert代替 |
git stash |
暂存当前工作区的改动 | 临时切分支修bug时，这个命令救过我很多次 |
git rebase -i HEAD~3 |
交互式变基，合并最近3个commit | 提交历史太乱时，我用它整理成一条干净的线 |
小技巧：我习惯给Git配置别名。比如git config --global alias.lg "log --oneline --graph --all"，这样输入git lg就能看到漂亮的分支图。省事。
分支策略：Git Flow vs Trunk Based
分支策略这东西，说白了就是团队怎么协作写代码。我见过两种主流方案：Git Flow和Trunk Based。各有各的适用场景，别盲目跟风。
Git Flow：老牌经典，适合大项目
Git Flow把分支分成了五类：master、develop、feature、release、hotfix。听起来复杂，但用熟了其实挺清晰。
- master：只存稳定版本。每次合并到master，都意味着一次发布。
- develop：日常开发的主分支。所有feature分支都从develop拉出来，最后合并回去。
- feature/xxx：每个新功能一个分支。开发完成后合并到develop。
- release/x.x.x：准备发布时，从develop拉一个release分支。只修bug，不加新功能。修完后合并到master和develop。
- hotfix/x.x.x：线上出紧急bug时，从master拉出来。修完后合并到master和develop。
我在一个金融项目里用过Git Flow。项目周期长，版本发布有严格流程，Git Flow的清晰结构帮了大忙。但说实话，它也有缺点：分支太多，合并频繁，小团队容易晕。
避坑指南：我曾经遇到一个团队，Git Flow用成了「Git Flood」。每个人都在拉分支，但没人及时合并。最后develop分支上积压了几十个未合并的feature分支，冲突解决花了一周。所以，Git Flow的关键是「及时合并，别拖」。
Trunk Based：现代敏捷，适合快节奏
Trunk Based的核心思想就一句话：所有开发者都在主分支（trunk）上开发，通过短生命周期的特性分支或直接提交来协作。说白了，就是「别搞那么多分支，大家都在一条线上干活」。
- 主分支：永远是稳定的，随时可以发布。
- 特性分支：生命周期极短，一般不超过两天。开发完立刻合并回主分支。
- 没有develop分支：主分支就是develop。
- 频繁提交：每天至少提交一次，甚至多次。
我现在带的团队就用Trunk Based。为啥？因为我们做SaaS产品，每天都要发布好几次。Git Flow那种长周期分支，根本跟不上节奏。你想想看，要是每次发布都要走release分支、打tag、再合并，一天发五次不得累死？
但Trunk Based也有门槛。它要求团队有很强的自动化测试能力。因为大家都在主分支上改，一旦有人提交了有bug的代码，整个团队都会受影响。嗯，所以CI流水线必须跑得飞快，测试覆盖率得高。
怎么选？我给你个建议
别纠结，看你的场景：
- 项目周期长、版本发布有固定节奏（比如金融、嵌入式）：选Git Flow。它的结构清晰，适合多人协作。
- 产品迭代快、每天多次发布（比如SaaS、互联网）：选Trunk Based。它的效率高，适合敏捷开发。
- 小团队、项目简单：选Trunk Based的简化版。别搞复杂了，简单点好。
我个人习惯是：新项目先用Trunk Based跑起来，等团队规模大了、发布流程复杂了，再考虑引入Git Flow的某些元素。别一开始就搞大而全，容易把自己绕进去。
总结一下：Git是工具，分支策略是方法论。工具用不好，方法论再牛也白搭。所以，先把Git的核心概念和常用命令练熟，再根据团队情况选分支策略。嗯，这一章就到这，下一章咱们聊聊CI/CD流水线的第一个环节——代码检查。