【GIT工作流指南】【六】企业日常开发模式探索

  1. 1. 企业日常开发模式探索
  2. 2. 更新 2016-11
  3. 3. 几篇业界的讨论文章
  4. 4. 博主使用的git客户端应用

xirong 结合自己所在公司使用git的版本分支开发过程,进行了总结。

企业日常开发模式探索

在看这部分前,请先回顾阅读业界认可的成功的 Git Branch Work Flow 模型 A Successful Git Branching Model ,了解日常开发中的场景,有助于熟悉下面的使用过程。

在企业开发中,使用 Git 作为版本控制软件最看重的还是结合公司自己搭建的 Gitlab,将 Code Review 加入打包部署持续集成的流程中,这样,代码开发完成,提交测试前,便可以对开发人员提交的代码进行 Review,发现潜在的问题,及时指导,对于新人来讲,也能更快更好的学习。

解决的需求场景如下:

  • 能支持日常迭代开发、紧急线上bug修复、多功能并行开发
  • 大概50人左右的团队,平日迭代项目较多,且周期短(1~2周一个迭代)
  • 能够通过tag重建整个系统
  • 支持code review
  • 所有上线的代码必须都是经过测试保证,且能自动同步到下一次的迭代中
  • 能和公司的项目管理/持续集成系统整合

图片

上图就是 xirong 团队在日常开发中总结出来的适合企业开发的模式,下面进行简单的介绍,方便大家学习了解。(本模式适合敏捷开发流程)

  1. 迭代需求会、冲刺会后确定本次迭代的目标后,将迭代内容视为一个项目,在 Gitlab 上创建一个 Repository,初始化工程代码结构,根据上线日期,比如20150730上线,开出分支 release20150730、dev20150730 两个分支,dev 分支作为日常开发主干分支,release 分支作为提测打包、Code Review 的分支。
  2. 迭代开始,日常开发进行中,开发人员在 dev 分支上进行 Commit、Push 代码,并且解决掉日常协同开发中的冲突等问题,等到达到提测条件的时候,提测者,首先 Merge Master 分支上的最新代码 git merge --no-ff origin/master ,使得 Master 分支上的变更更新到迭代开发分支dev上面,之后,在 Gitlab 上面发起 pull request 请求,并指定 Code Review 人,请求的分支选择本次上线的 release 分支,即 release20150730。
  3. 被指定 Code Review 的人,对发起者的代码 Review 后,决定是否可以提交测试,若有问题,评论注释代码后,提交者对代码进行进行修改,重复步骤2,直到代码 Review 者认为 Ok。之后便可以借助自己公司的打包部署,对这些代码发布到测试环境验证。
  4. 步骤2-3重复多次后,就会达到一个稳定可发布的版本,即上线版本,上线后,将 release 版本上面最后的提交(图中0.2.4上线对应处)合并到 Master 分支上面,并打 Tag0.3。至此,一次完整的迭代开发完成。
  5. 若此次上线后,不久发现生产环境有 Bug 需要修复,则从 Tag 处新开分支 release_bugfix_20150731、dev_bugfix_20150731 ,开发人员从 dev_bugfix_20150731分支上进行开发,提测code review在 release_bugfix_20150731 分支上,具体步骤参考2-3,测试环境验证通过后,发布到线上,验证OK,合并到 Master 分支,并打 Tag0.2.3,此次 Bug 修复完毕,专为解 Bug 而生的这两个分支可以退伍了,删除release_bugfix_20150731、dev_bugfix_20150731两分支即可。(所有的历史 Commit 信息均已经提交到了 Master 分支上,不用担心丢失)

这样经过上面的1-5步骤,企业日常迭代开发中的代码版本控制基本上就 Ok 了。

更新 2016-11

Git 分支开发部署模型 的一些使用原则如下:

  • master:master永远是线上代码,最稳定的分支,存放的是随时可供在生产环境中部署的代码,当开发活动告一段落,产生了一份新的可供部署的代码时,发布成功之后,代码才会由 aone2 提交到 master,master 分支上的代码会被更新。应用上 aone2 后禁掉所有人的 master的写权限
  • develop:保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码,只对开发负责人开放develop权限。
  • feature: 功能特性分支,每个功能特性一个 feature/ 分支,开发完成自测通过后合并入 develop 分支。可以从 master 或者develop 中拉出来。
  • hotfix: 紧急bug分支修复分支。修复上线后,可以直接合并入master。

Git-Develop 分支模式是基于 Git 代码库设计的一种需要严格控制发布质量和发布节奏的开发模式。develop 作为固定的持续集成和发布分支,并且分支上的代码必须经过 CodeReview 后才可以提交到 Develop 分支。它的基本流程如下:

  • 每一个需求/变更都单独从Master上创建一条Branch分支;
  • 用户在这个Branch分支上进行Codeing活动;
  • 代码达到发布准入条件后aone上提交Codereview,Codereview通过后代码自动合并到Develop分支;
  • 待所有计划发布的变更分支代码都合并到Develop后,系统再 rebase master 代码到Develop 分支,然后自行构建,打包,部署等动作。
  • 应用发布成功后Aone会基于Develop分支的发布版本打一个“当前线上版本Tag”基线;
  • 应用发布成功后Aone会自动把Develop分支的发布版本合并回master;

几篇业界的讨论文章

博主使用的git客户端应用

单工程管理GitKraken;
多工程管理giteye;
附:文档管理 zeal(windows) 或者 dash(macos、IOS)

最终还是建议读者去看一下git官方的书:git-scm

欢迎访问博客地址:https://www.zhoyq.com