你有没有试过在厨房里同时做好几个菜？一边炖汤，一边炒菜，还得蒸个鱼。要是没点章法，锅碗瓢盆乱成一团，最后连盐都忘了放几次。写代码也是一样，多人协作、功能迭代、紧急修复，全挤在一个地方改，不出三天项目就得“烧糊锅”。
主干就像家里的灶台
家里做饭，灶台是主力，天天用，不能随便动。代码的主干分支（main 或 master）也一样，得保持稳定。谁也不能随随便便往里扔半生不熟的代码，就像没人会把生肉直接摆上餐桌。
功能分支：每道菜单独起锅
要做红烧肉，就单独开个锅，别跟清炒时蔬混一起。在开发中，每个新功能都该从 main 拉出一个 feature 分支，比如 feature/user-login。做完测试通过，再合并回去。
git checkout main
git pull
git checkout -b feature/user-login这就像你备菜时把葱姜蒜先切好，装盘备用，啥时候要用拿一碟就行，不影响主流程。
发布分支：出菜前的摆盘检查
菜快好了，得尝一口、摆个盘、看看有没有头发。发布前也得这样。当你准备上线 v1.5 版本，可以从 main 拉个 release/v1.5 分支。这时候只修 bug，不加新功能，确保端上去的菜干净利落。
热修复分支：汤咸了怎么办？
客人已经端碗了，发现汤咸了，咋办？不能把整锅倒掉重做吧。这时候就得搞个 hotfix 分支，比如 hotfix/salt-fix，快速修正，打个补丁，再同步到 main 和 release 分支。
git checkout main
git checkout -b hotfix/salt-fix
# 修改代码后提交
git commit -am "Fix over-salted soup"
git merge hotfix/salt-fix修完马上上线，就像厨房里赶紧兑点水，重新盛一碗，客人甚至没察觉。
别让分支变成冰箱里的剩菜
有些人分支用完不删，feature/login-v2-old、temp/bak2、maybe-later……时间一长，仓库比冰箱还乱，打开全是不知道啥时候的东西。合进主干的分支，及时清理，省得以后翻车。
代码分支策略不是教条，就跟做菜没有绝对标准一样。有人喜欢先腌肉，有人现炒现拌，关键是适合自己团队的节奏。只要别让项目变成一锅乱炖，那就还算有谱。