第3章版本控制选型

版本控制选型：Git vs SVN，GitFlow vs Trunk-Based，GitLab vs GitHub vs Bitbucket

版本控制这件事，说白了就是团队的「后悔药」和「时光机」。我见过太多团队在这上面栽跟头——选错了工具，后面整个CI/CD流水线都得跟着改。今天咱们就把这块掰开揉碎了聊。

先说说SVN。我记得2015年刚入行时，公司还在用SVN。那时候觉得「集中式管理」天经地义，所有代码都锁在中央服务器上，谁改了谁负责。但后来我接手了一个跨国项目，问题就来了——

团队成员分布在三个时区，SVN的离线工作能力几乎为零。你想想看，飞机上想改个bug，没网就干瞪眼。Git的分布式特性完美解决了这个问题。每个人本地都是完整仓库，提交、分支、合并全在本地完成。

核心差异对比：

我个人习惯是：新项目一律用Git。但如果你维护的是老旧的SVN仓库，也别急着迁移。我曾经帮一个金融客户迁移过，光历史记录就折腾了两周。嗯，这里要注意——SVN的目录结构通常和Git的tag/branch概念不兼容，迁移前一定要做好映射方案。

避坑指南：我曾经见过一个团队，把SVN的trunk直接映射成Git的master，结果所有历史tag全乱了。正确的做法是：先用git-svn工具做增量迁移，保留完整的提交记录和分支关系。

选完Git，下一个问题就是：分支策略怎么定？GitFlow和Trunk-Based是两大主流流派。

GitFlow是我最早接触的模式。它有master、develop、feature、release、hotfix五类分支，结构清晰得像教科书。但说实话，我在实际项目中用下来，发现它有个致命问题——太复杂了。

举个例子：一个紧急hotfix，你得从master拉分支，修完合并回master和develop，再打tag。这一套流程走下来，光分支操作就五六步。对于小团队来说，这简直是灾难。

Trunk-Based就简单多了。所有开发都在主干（trunk或master）上，通过短生命周期的特性分支（feature branch）来隔离风险。我现在的团队就用这个模式，每天合并几十次，配合CI流水线，基本不会出现大冲突。

选型建议：

你想想看，如果你的团队每天发布多次，用GitFlow光合并就能把人逼疯。我有个朋友在电商公司，双十一期间用Trunk-Based，一天发布20多次，毫无压力。

注意：Trunk-Based对CI/CD要求很高。如果你们的自动化测试覆盖率低于80%，我建议还是先用GitFlow稳一稳。我曾经吃过这个亏——测试不充分，主干上直接出生产事故，回滚都来不及。

这三个平台我都深度用过。GitHub是社区之王，GitLab是自建神器，Bitbucket是Atlassian生态的宠儿。

GitHub：开源项目首选。社区活跃度无人能及，Actions功能也越来越强。但企业级功能（比如代码审查、权限管理）需要付费，而且服务器在国外，国内访问偶尔抽风。

GitLab：我现在的团队就在用。它最大的优势是「一体化」——从代码托管到CI/CD到容器镜像仓库，全在一个平台里。而且支持自建，数据安全可控。我记得有一次客户要求所有代码必须留在国内，GitLab自建方案完美解决。

Bitbucket：如果你公司已经在用Jira、Confluence，那Bitbucket是天然选择。它的代码审查和Jira集成做得特别好，但CI/CD能力偏弱，通常需要搭配Bamboo或Jenkins。

我的建议：

最后说说企业级选型。我参与过三次大型版本控制迁移，总结下来就三条原则：

最终决策矩阵：

嗯，最后说一句：工具是死的，人是活的。我见过用SVN也能跑出高效流水线的团队，也见过用Git但分支管理一塌糊涂的。选型只是第一步，真正的功夫在落地执行上。

下一章咱们聊聊CI/CD工具链的选型，到时候我会分享一些Jenkins和GitLab CI的实战对比，敬请期待。