分支模型是团队协作的「交通规则」：它规定代码怎么流、谁能合、什么时候能发。选错模型不会立刻出事，代价会以「合并越来越难、主干越来越不敢发」的形式慢慢累积。

1. 分支的本质

在 Git 里，分支就是一个指向某次提交的可移动指针，.git/refs/heads/ 下只是一个存着提交哈希的小文件。创建分支是写一个 41 字节文件，切换分支是改一下 HEAD 并更新工作区——所以 Git 的分支又快又廉价，随便建、随便删。

正因为分支廉价，「分支模型」讨论的从来不是技术成本，而是协作约定：什么时候开分支、分支存活多久、如何合回主干、发布怎么打、事故怎么修。下面三种模型对应三种协作节奏。

Git 是分布式版本控制系统（Distributed Version Control System, DVCS）：每个克隆都是一份带完整历史的仓库，不依赖中央服务器也能提交、查看历史、创建分支。它真正解决的问题不是「存副本」，而是「让多人在同一份代码上并行改动、且任何一步都能回退」。

1. 为什么是 Git

初级做法是给目录加时间戳备份（code_final_v2.zip），问题很快暴露：

• 找不到「谁、在什么时间、为什么」改了某一行，无法追责与追溯。
• 两个人改同一文件只能人工合并，冲突时容易覆盖对方的修改。
• 想试验一个新方案，只能复制整个目录；试错成本高，就不敢改。
• 想回滚到「上周三能用的版本」，只能靠记忆和运气。