关于分支

[JaysonAlbert]

1. bug修复推相应分支，哪个分支的bug推哪个（包含master）
2. 大功能的增加，新建相应的独立分支，例如asyncio版本接口，就新建asyncio分支。
3. 小功能的增加或者修改， 推dev分支。
4. dev分支累计较多功能且稳定后，合并到master分支。大功能独立分支稳定后，合并到master分支。

[inevity]

• 建议一种方法release trains的方法
  master分支是前进分支，几乎所有commit首先到这个分支，保证可build和安装，基本的测试通过。从master，我们需要一个版本2.x系列，我们可以创建release-2.x分支，如果稳定了，我们可以打一个tag，比如2.1版本。之后在这个release2.x分支上不再增加新功能，只是进行bug修复。如果bug多了，可以打另一tag比如2.2版本。对于release2的bug，首先要bug fix在master上，然后移到release2的分支上。 这样对每一个release，比如2.xrelease，我们可以有2.1，2.2，2.3版本，对于3.x版本，我们有3.1,3.2,3.3等。
• 针对于咱们的目前的分支策略
  1. 可以认为原来的dev分支，可以作为release trains的方法的master分支，原来的master可以作为一个release版本,比如releas -1.1.0，，从其中我们tag生成需要的包版本，比如1.1.0.11版本。(不清楚这里版本四部分啥意思）
  2. 第二种思路(这个看起来容易）： 原来的master分支可以作为release trains的方法的master分支，以后所有的新功能和bug修复首先进入master分支。从其中我们创建一系例release版本。 原来的dev分支可以忽略了，当我们开发一个新功能时，基于master创建一个分支（比如那个async branch），待分支实现完成基本稳定后然后合并到master。

[JaysonAlbert]

看到一篇文章是讲这个的，第二篇是第一篇中提到的 https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ http://nvie.com/posts/a-successful-git-branching-model/ 第二篇文章批判了第二篇的，并自己提出了一种模型。第二篇的模型有一个git project，做了一个工具专门用来管理分支

[JaysonAlbert]

@inevity 你提出的方法比较偏向于第一篇文章中的方法。我们现在的分支比较乱，迁移到你说的这种分支模型的话，倒是比较容易，迁移到上面的第二种被批判的那种，反而会更麻烦一点。我也比较偏向于你这个方法。

现在的话，相当于，master分支继续走，只需要新建一个release分支管理release就可以了。

[inevity]

恩，对，刚开始，也许只要一个release分支比如release1.x就可以了，后面如果功能差别太大，可以再建一个release分支release2.x。好多大型项目都是采用这种分支机制的。