qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

【过程改进】总结大中小型项目的git流程

  git作为源码管理工具出于流行趋势。这里和大家一起分享下我们是如何用git的分支(branch)功能管理不同规模的项目
  小型项目
  推荐工具:TortoiseGit
  开发阶段(第一版上线前):2个分支 develop和master
  由于是项目参与人员不多,基本上很少会有不同角色的人员出现职责冲突,需求变更也不会很繁冗。这种情况值我们只需要主要功能分支。
  其中develop负责开发版本,master相当于预上线版本。
  develop过程如果出现代码冲突,手工merge就好。
  开发阶段(第一版上线后):3个分支 develop、master、hotfix
  多处于来的hotfix用于紧急上线(bug,新需求等)。hotfix基于master,因为develop已经越走越远,基于develop的hotfix会将带上一些当前不想上线的新功能。
  hotfix完成后hotfix要merge到master上,因为线上不管何种情况都是master版本。qa完成测试并且上线后要将master版本merge到develop避免hotfix的修改在develop中丢失。
  维护阶段(停止常规开发):2个分支 master、hotfix。
  这个阶段就相当于针对上线版本的各种打补丁了。
  中型项目
  推荐工具: sourcetree
  开发阶段(第一版上线前):3个分支 feature、develop和master
  相对于小型项目多了feature分支的概念。feature分支基于develop分支,当功能开发完成后merge回develop。
  这样做的好处是将develop分支从小型项目中去中心化。举个例子,因为是中型项目,我们可能有5 6个在并行开发,如果这个过程中客户说某个功能我们不要了,我们可以很轻松的丢掉某个feature分支而不必污染develop。
  但是如果是开发时间很久的feature分支,很可能会因为不定时的merge develop或者需求的不断变更等导致当前分支的commit比较肮脏。所以对于feature分析的力度要控制好。
  如图所示:
  开发阶段(第一版上线后):4个分支 feature、develop、master和hotfix
  和上面小心项目一样 hotfix基于master版本。
  维护阶段(停止常规开发): 和小型项目一样 大型项目
  推荐工具:sourcetree
  大型项目相对于中型项目又多了release版本。这个版本的作用只要是控制需求的更新以及当前版本bug的fix处理。
  点击查看大图:
  对于这种情景sourcetree自带git-flow的功能
  并且给出各种引导提示
  和中型项目相比,hotfix分支在大型项目中只处理线上的bug问题。对于需求的控制,都会发生在release分支中。一个release版本的生成并不意味着它可以直接提交master,qa的介入在中小型项目中属于master分支,
  但是在这个流程下,qa的介入属于release分支,包括对于bug的修复操作也是直接在release版本完成。当qa对于release版本确认完成后,release版本merge到master预上线并且merge回develop保持代码一致性。

posted on 2014-07-15 10:24 顺其自然EVO 阅读(161) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜