分支策略总结

前几日在发布新版本时,发现 SVN 的分支策略有问题,然后读了 SVN 的常见分支模式,依照文章里的模式改变了分支策略,貌似解决了问题。但我对之前用的策略还是念念不忘,经过调查和思考,得出结论:之前用的策略也没有问题,and what’s more,那是 Git 更常用的分支模式,但更适合于开发流程规范、并严格遵循的项目。

在 Git 分支模型的阐述上,Vincent Driessen 的 A successful Git branching model 是一篇很多人认为不错的文章,译文也已经有好几篇了:介绍一个成功的 Git 分支模型Git 分支的最佳实践一个成功的Git分支模型

个人认为,这篇文章阐述的分支模型是非常不错的,但遣词造句上实在有些繁琐,读起来很费劲,不过绝对值得一读。

下面是我对分支策略的总结。

Subversion 和 Git

  1. Git 是分布式的版本控制系统,所有人都拥有一个仓库,而不仅仅是一个 working copy。但依然要有一个远端的中心,称为 origin。相对的,Subversion 是集中式的版本控制系统,仓库只在远端。
  2. Subversion 的三大部分是 trunk、branches、tags,即主干、分支、标记。相对的,Git 没有 trunk 的概念,主干可以认为是 master 分支,也是分支之一。
  3. Git 的分支才是真正意义上的分支。相对的,Subversion 在本质上不存在分支,所谓分支只是目录的拷贝。
  4. Git 在分支与合并方面是简单易行的。相对的,Subversion 的分支与合并总是让人恐惧。

分支模式一(Git 风格)

  1. 长期分支有主分支(master)和开发分支(develop),短期分支有特性分支(feature)、预发布分支(release)、补丁分支(hotfix)。
  2. master 分支,始终 保存每次发布的版本,HEAD 则指向当前发布的最新版本。日常的开发工作不直接在主分支进行。
  3. develop 分支,其中为 下一次 要发布的版本(而不包含下次的下次发布应包含的功能)。
  4. feature 分支,开发某项新特性时使用。这项特性可能在下一次发布时加入软件,也可能在下次的下次发布时才加入软件。也有可能是实验性质的特性,最终可能得以加入软件,也可能效果不好直接抛弃。它应从 develop 分支出,开发完毕后合并回 develop 或直接丢弃。注意并回的时机,是要在 下次发布的版本 中引入这个特性时,而 不是 下次的下次发布时。合并完毕后,应将这个 feature 分支删除。
  5. release 分支,在某一版本准备发布时使用。在 develop 分支已经可以进入发布前的测试时,从 develop 分支出,命名为 release-1.0。测试过程中的 bug 修复,应提交到该分支。测试结束可以发布时,将该分支合并回 master 分支和 develop 分支,并给 master 分支打一个 tag(如 1.0)。然后,将这个 release 分支删除。需要注意的是,合并回 master,是因为这将成为一个新的发布版本;合并回 develop,是为了将 release 分支中对 bug 的修复也合并回 develop 分支,更好的方式是随着测试而不断地将 bug 修复合并回 develop,避免最后才一次性合并。
  6. hotfix 分支,在线上版本出现 bug 需要紧急修复时使用。在 master 分支出,命名为 hotfix-1.0.1。在完成修复代码并通过测试后,合并回 master 和 develop,并对 master 打一个 tag(如 1.0.1)。然后,将这个 hotfix 分支删除。

分支模式二(Subversion 风格)

  1. trunk 主干,日常的开发工作直接在 trunk 进行。
  2. 长期分支有发布分支(release),短期分支有特性分支(feature)。
  3. release 分支,在某一版本准备发布时使用。在 trunk 中的开发已经可以进入发布前的测试时,从 trunk 分支出,命名为 release-1.0。测试过程中的 bug 修复,应提交到该分支。测试结束可以发布时,将该分支合并回 trunk,并给该 release 分支打一个 tag(如 1.0)。注意,这个 release 分支将 永久保留 ,之后的 hotfix 也将在此分支进行。
  4. feature 分支,开发某项新特性时使用。这与分支模式一里的 feature 分支完全相同,唯一不同的是,它从 trunk 分支出,并最终合并回 trunk 或直接丢弃,最后被删除。

Then which one?