使用Git进行团队合作开发版本管理原则

 Git 是最流行的版本管理工具,我也是刚刚接触git,系统的学习了下Git的团队开发Branch Model,发现网上已经给出的最佳实践如下:

更详细的信息,请直接参考原文章链接:

http://nvie.com/posts/a-successful-git-branching-model/ (最佳实践的来源,强烈推荐读一下)。

http://www.ruanyifeng.com/blog/2012/07/git.html (上一篇文章的中文翻译和简化,没有原始文章清晰)

http://scottchacon.com/2011/08/31/github-flow.html (git-flow 根据第一篇的最佳实践总结出来的模式性的东西)

 

最佳实践如下(源于最佳实践一文):

 

Git Branch Model

 

  1. 任何系统或项目都常备两个 Branch, Master 和 Developer,这两个branch 永远不会删除。
  • Master branch 标志了系统的最初版本和稳定功能,如果Master branch 有提交,那么一定表示有新的稳定功能或者 bug 修改,需要重新发布新版本。版本策略由项目组独立制定,比如较大的功能发布,可以升级大版本 (v1.1.0 -> v1.2.0), hot bugfix 可以发布小版本 (v1.1.0 -> v1.1.1)等。

  • Develop branch: 最初是从 Master branch 拉出。是功能开发的 upstream branch 所有开发的功能都要 merge 到 此 branch,进行最终的集成或回归测试。如果测试通过了,那么会将功能merge 回 master(注意不是直接merge,下面会讲到),进行正式的发布。

    2. 中间的branch,随需要拉出,功能执行完成后删除。主要包括如下几种:

 

  • feature branch。故名思议,feature branch 是真正的功能开发的branch。为什么 feature branch,而不是直接在 develop branch 上开发? 因为团队合作! 如果需要并行的开发多个feature,那么在一个 develop branch上开发明显是不合适的,不内聚,容易造成错误。每个 feature 开发,都需要单独从 develop branch 拉出一个独立的feature 分支,开发并测试完成后,需要在合并到 branch 分支,然后进行验证和回归测试。确认没有问题后,删除 feature branch。
  • release branch。release branch 专门用于预发布的。 feature branch上进行了功能的开发,测试通过,并合并到develop branch 上了。这时可以发布新的功能了。为什么不直接从 develop branch merge 到 master branch 并直接发布? 因为在发布的时候,我们可能还需要做一些细节上的微调工作比如开发时版本号可能是 snapshot,到正式环境上需要去掉 snapshot,比如需要连接正式的数据库进行下验证,修复下验证中发现的一些bug。这些都是在 release branch 上进行的。release branch 工作完成后,需要 merge 到 master branch,正式发布。注意 release branch 也要 merge 回 develop 分支,确保所有的修改都同步到了 develop 分支。
  • hotfix分支。上面的分支已经能够确保我们从开发到上线的流程都成功了。但是有时候在线上会发现一些比较hot 的bug,需要立即修复。这个时候走正常的 feature release 到发布显然是不能满足要求的。此时应该直接修改 master ,并合并到 develop branch. 这就是 hotfix branch 存在的理由。从 master branch 拉出 hotfix branch,bug fix 并验证后,合并到 master 和 develop。

 具体的拉出分支的命令及merge 命令,请参考最上面推荐的链接。

展开阅读全文

没有更多推荐了,返回首页