在开发软件或维护文档时，很多人会遇到团队协作的问题。比如，小李和小王一起写一个项目，小李改了代码后发给小王，小王又在旧版本上做了修改，结果两人的改动对不上，最后还得手动比对。这种混乱的情况，靠“文件重命名”比如“最终版_1”、“最终版_2”根本解决不了。这时候就得靠版本控制。
集中式版本控制：像公司档案室
集中式版本控制系统，比如 SVN，它的核心是一台中央服务器。所有人的代码都往这台服务器提交，就像公司里所有合同都要归档到档案室一样。每次你开始工作前，先从服务器“签出”最新版本；改完后再“签入”回去。
这种方式结构清晰，管理员能严格控制谁可以改哪部分。但问题也很明显：一旦服务器宕机，所有人都没法提交新版本。更危险的是，如果服务器上的代码被恶意篡改或删除，整个项目的版本历史可能就丢了。这就像是档案室着火，所有合同都没了备份。
分布式版本控制：每个人的电脑都是仓库
Git 是典型的分布式系统。它最大的不同是，每个人本地都有完整的代码仓库，包括全部历史记录。你提交代码不需要依赖中央服务器，哪怕公司网络断了，你照样能正常提交、查看历史。
这种设计天然抗故障。就算中央仓库被攻击或丢失，随便一个人的本地副本都能恢复全部数据。而且，因为每次提交都会生成唯一的加密哈希值，一旦有人偷偷修改历史记录，系统立刻就能发现。
git clone https://example.com/project.git
git add .
git commit -m "修复登录漏洞"
git push origin main上面这段命令就是日常操作：先克隆项目，添加更改，提交并推送到远程。每一步都有记录，谁在什么时候改了什么，清清楚楚。
安全角度怎么看？
集中式系统权限管理简单，适合对合规要求高的企业，比如银行内部系统。但它的单点风险太大，一旦中心被攻破，后果严重。
分布式系统虽然灵活，但也带来新挑战。比如开发者不小心把数据库密码提交到代码里，就算删掉，历史记录里还能挖出来。所以用 Git 时得配上 .gitignore 文件，再结合代码扫描工具，防止敏感信息泄露。
很多公司现在用的是混合模式：用 Git 做分布式开发，再通过 GitHub 或 GitLab 设定严格的合并规则。比如必须两人审核、自动跑安全检测，才能把代码合并进主干。这样既保留了分布式的安全性，又加强了管控。