关于分支管理

今天看了一篇文章，讲分支管理的，他的原则是这样的：

一开始就只有一个分支，全部人力都在这个分支上

谁都可以要求开分支，但需要解决两个问题：

2.1 谁来提供人力来维持这个分支（本质上市场收益是否能支持这个分支的投入），这个人力是否足够

2.2 为这个分支定义一个Topic，然后证明这个Topic和现有的所有Topic有足够的不同。这同时也定义了这个分支的生命周期。

考虑手段把这个分支的有益修改收回到主线分支上

看完之后我感觉深感认同，但是现实总是很多妥协和不可预测的。在这里我讲下我的一个被分支管理折磨的经历：

我们的一个产品，这里把它叫做A吧，A开始有两个版本，一个通用版本，一个VPC版本，但是其实差距没有特别大，所以我们就弄了个environment的参数来判断，但是随着时间过去，我们这里版本增多了起来，通用版本、VPC版本、交付版本、XX地版本，于是乎版本管理开始复杂了起来，因为这个产品分了很多个仓库，这些environment也没有一个稳定的文档来说明，所以就导致了新人来的时候就会被这些东西搞的很头大。其实单是这些勉强还在控制范围内，因为差距不大，可能是一个地址的不同，可能是一个文案描述的不同，不算特别大的改动。但是某天突然有一个较大的版本不用，我们一直在讨论是不是应该新开一个仓库，而不是新拉一个版本，因为这个版本功能可能永远都不会合并到主线，单独维护这样一个分支其实是很危险的，因为ci会检测每个分支和主线的差距，如果差距过大甚至不会让他打包通过。但是如果分一个仓库维护起来又是一个很大的问题，而且这些功能完全不能说是需要重新建一个仓库的地步。

不过最终的结果却是是重新开了一个仓库，然后又多了一个需要维护的仓库，一次功能同步忘记会导致很多问题。

其实写代码越久越发现人其实是最不可靠的，一个人无论多么细心总会出现问题的，而对于一些发布的东西，一个地方发生错误就可能引发很严重的后果，所以这就是为什么很多人都推崇自动化发布，因为自动化发布避免了人的错误，机器，或者说计算机，最擅长的就是重复的执行操作，而让人重复一样的操作是有点反人类的，所以忘记同步的事情也是发生过，直到后来出文档，每次照着文档来更新版本和发布，才算解决了一部分的问题。