版本控制基础：Git核心概念与工作流
聊到CI/CD，版本控制是绕不开的基石。说实话，没有Git，持续集成就是个空壳子。我见过太多团队，代码管理混乱，合并冲突搞得人仰马翻。今天咱们就把Git的核心概念、工作流和平台选择，一次性讲透。
Git核心概念：仓库、提交、分支、合并
先说说仓库。仓库就是存放代码的地方，分本地和远程两种。本地仓库在你电脑上，远程仓库在服务器上。我刚开始用Git时，总搞不清这两个的关系。后来想明白了——本地仓库是你干活的地方，远程仓库是大家协作的地方。
提交是Git的灵魂。每次提交就像拍了一张快照，记录下当前所有文件的状态。我个人习惯是：每次提交只做一件事，改动尽量小。比如修复一个bug，就只提交那个bug的修复代码。别把格式化代码和功能修改混在一起，否则回滚时你会哭的。
分支是Git最强大的功能之一。你可以把分支想象成平行宇宙。主分支是稳定的生产环境，其他分支是开发中的新功能。我曾在项目中遇到一个坑：有人直接在master分支上改代码，结果上线前发现还有bug没修完，整个版本都回滚了。嗯，从那以后我强制要求：所有开发必须在分支上进行。
合并是把分支的改动合并到另一个分支。这里有个常见问题：合并冲突。为什么会冲突？因为两个人改了同一个文件的同一行代码。我曾经处理过一个特别棘手的冲突，两个同事改了同一个配置文件，一个加了新功能，一个修了bug，结果合并时乱成一锅粥。最后只能手动逐行比对，花了整整一下午。
Git工作流：GitFlow vs GitHub Flow
工作流说白了就是团队协作的规矩。没有规矩，代码管理就是一团乱麻。我见过两种主流的工作流：GitFlow和GitHub Flow。
GitFlow
GitFlow是2010年提出的经典工作流。它定义了五个分支：master、develop、feature、release、hotfix。听起来复杂，但用起来很清晰。
- master分支：只存放稳定版本，每次发布打一个tag
- develop分支：日常开发的主分支，所有feature分支从这里拉出
- feature分支：开发新功能，完成后合并回develop
- release分支：准备发布时从develop拉出，只修bug，不添新功能
- hotfix分支：线上紧急bug，从master拉出，修完后合并回master和develop
我个人觉得GitFlow适合大型项目，版本发布周期长，需要严格管控。但缺点也很明显——分支太多，操作繁琐。我曾在团队里推行GitFlow，结果新人光记分支规则就花了一周。
GitHub Flow
GitHub Flow就简单多了。它只有一个主分支master（现在叫main），所有开发都在feature分支上进行，通过Pull Request来合并。流程是这样的：
- 从main拉出feature分支
- 在feature分支上开发
- 提交代码，推送到远程
- 创建Pull Request
- 代码审查通过后合并到main
- 立即部署
GitHub Flow适合快速迭代的项目，比如互联网产品。我现在的团队就用这个，每天能发布好几次。说白了，GitHub Flow就是"小步快跑"的实践。
代码托管平台选择
选平台就像选房子，得看需求。目前主流的有GitHub、GitLab、Gitee。我三个都用过，说说感受。
| 平台 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| GitHub | 社区活跃、生态完善、Actions强大 | 国内访问慢、私有仓库收费 | 开源项目、国际团队 |
| GitLab | 自托管、CI/CD集成好、免费私有仓库 | 界面稍复杂、社区不如GitHub | 企业内网、需要自建 |
| Gitee | 国内访问快、中文支持好、免费私有仓库 | 功能不如前两者、社区较小 | 国内团队、需要快速访问 |
我个人习惯：开源项目放GitHub，公司项目用GitLab自托管，国内小团队用Gitee。你想想看，如果团队都在国内，用GitHub每次拉代码都要翻墙，多耽误事。
好了，版本控制基础就聊到这儿。记住：Git是工具，工作流是规矩，平台是载体。三者配合好，CI/CD才能跑得顺。下一章咱们聊聊持续集成环境的搭建，到时候见。