Git学习手记13:分支(branch)管理策略

上一节《Git学习手记12:多人协作(Collaboration)、工作流(workflow)与分支(branch)》

实际开发工作中，我们常常与下面的工作打交道：

1，维护一个稳定可靠的版本，随时可以发布

2，根据当前软件需求书，开发功能

3，调试发现的Bug

4，开发一些未来可能会用到的新功能

最简单的实现方式：master分支存储了正式发布的历史，维护稳定可靠的版本；develop分支作为功能的集成分支，用于开发、调试；

成熟一点的方式是：

用master分支存储了正式发布的历史，master分支上所有提交都分配一个版本号

用develop分支记录开发工作的历史

当要开发新功能的时候，以develop分支为父分支，从develop分支中拉出一个future分支，记录开发的新功能；新功能开发好了后，再合并到develop分支。新功能开发，追踪和提交不直接与master分支交互

一旦develop分支上有了做一次发布的足够功能，或者说快到了既定的发布日了，就从develop分支上fork一个release分支。

release分支用于追踪发布循环，例如：Bug修复、文档生成和其它面向发布任务等，从这个时间点开始之后新的功能不能再加到这个分支上了。

一旦对外发布的工作都完成了，release分支合并到master分支并分配一个版本号打好Tag。

从新建release分支以来的做的修改要合并回develop分支

使用一个用于发布准备的release分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能

热修复（hotfix）分支用于给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

下一节《Git学习手记14:Git实战》