【过程改进】总结大中小型项目的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保持代码一致性。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-29 03:30:07

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

提交PR的git 流程

前言 上次花了点时间让CarbonData集成到StreamingPro中,方便大家更快速的体验到CarbonData的好处,集成完毕后就写了篇文章:让CarbonData使用更简单 文章里面有下载链接,下载下来就能用,基本不需要你了解carbondata的知识就可以直接用. 然后集成过程中解决了不少问题,提交了个PR,因为社区你懂的,一般接受PR的速度都比较慢,尤其是一个快速发展的项目,master更新频率很快,而社区又对git log commit 之类的有一定的要求,而我之前参与的项目,要

软件项目的“管理之痒”

在国内,不少做过几年程序员,被同事.圈内的朋友公认为技术水平不错的人,在考虑自身职业发展的时候,可能会想当然的认为:"我可以做项目经理了,感觉做个项目经理也没啥特别难的". 但如果你真的有机会,去尝试带一个团队,哪怕是只有几个人的一个小TEAM的时候,你就会发现,你必须面对一系列的问题和麻烦,而这些事情的处理结果,基本上和个人技术水平无关. 举一些例子: "自己每天被领导施压,忙忙碌碌,累得吐血,可手下的几个人,却让人觉得他们闲的发慌". "给他们布置的任

openmeetings源码编译-不知道有没有大神研究openmeetings,使用的是3.0.3版本,使用ant+ivy构建依赖和项目的

问题描述 不知道有没有大神研究openmeetings,使用的是3.0.3版本,使用ant+ivy构建依赖和项目的 ant运行build.xml过程中老出错 <untar src="${red5.server.dir}/target/red5-server-${red5.server.version}-server.tar.gz" dest="${red5.server.dir}/target" compression="gzip"/>

CMMI过程改进之路——质量保证误区

如何提升产品质量在业界是一个永恒的话题,零缺陷是理想化的,永远只能作为目标而不能到达,客户基于市场压力和竞争等方面的考虑,优先考虑的往往是进度,如何定位质量保证(QA)角色.如何平衡进度.质量.成本的关系,是质量保证的核心关键,关于质量保证常存在下列误区: (1)组织架构中QA团队误区: 在不少公司,基于成本考虑,缺少了真正的高素质的质量保证人才,这其实是管理层的意识问题,认为设立QA岗位,人才的招聘.培训.薪酬.福利.工作环境的消耗将是一笔不小的成本支出,根本没有必要,实际上是一个不好的作法.

.gitignore详解(附上eclipse的java项目的 .gitignore文件)

今天讲讲Git中非常重要的一个文件――.gitignore. 首先要强调一点,这个文件的完整文件名就是".gitignore",注意最前面有个".".这样没有扩展名的文件在Windows下不太好创建,这里给出win7的创建方法: 创建一个文件,文件名为:".gitignore.",注意前后都有一个点.保存之后系统会自动重命名为".gitignore". 一般来说每个Git项目中都需要一个".gitignore&quo

改进型组织-过程改进组织最佳实践

改进型组织是一个平衡发展的组织,它由业务线.流程线.QA线.IT线.协调线共五线组成,简称五线谱组织. 业务线:负责产品质量.过程质量.为执行负责: 流程线:负责流程质量,为优化流程负责: QA线:负责识别流程执行偏差,提供执行的第三方可视性,为流程可视性负责: IT线:负责流程的IT化质量,为流程高效负责: 协调线:负责业务线.流程线.QA线.IT线的平衡发展,负责他们协同工作,为协同.平衡负责. 企业发展的初期,一般由业务线.IT线.协调线构成,IT线的工作一般是维护日常办公,确保其他人员正

成功部署物联网项目的10个步骤

在部署物联网项目前,请确保你采取了这些关键步骤,每个公司都想要在其大数据战略中利用物联网,但怎样实现这个目标呢?下面是成功部署IoT项目的10个步骤.   1: 学习他人经验 企业决策者都听到过有关物联网的炒作,但很多人不知道物联网如何能对业务带来实际影响.因此,企业在考虑部署物联网设备时,应该先花些时间与实际应用物联网的企业进行沟通,了解他们如何利用物联网. 2: 制定战略 每个企业都有独特的需求,并没有适合所有人的物联网项目.在你试验物联网或提交项目申请书之前,应该与企业关键决策者共同制定战

《个体软件过程》—第1章1.7节过程改进的步骤

1.7 过程改进的步骤个体软件过程改进工作方式所需要的步骤与我学习射击泥鸽子的步骤一样.它们并不复杂,如图1.1所示. 定义质量目标.很显然,我的目标就是尽我所能射中靶子.百发百中是我最终的目标.度量产品质量.教官和我都看到了我的糟糕成绩,觉得需要作些改进.了解过程.教官观察我的操作,看看我应该作哪些改变.对过程进行调整.教官建议我改用左手射击.应用调整后的过程.我用左手进行了几轮射击.度量结果.我们数了数我击中的和脱靶的鸽子数.将结果与目标作比较.从统计数据可以看出,我的成绩大大地提高了.循环

iOS开发:Git流程

 开发:Git流程-"> iOS开发中的Git流程 Git的优点相信已不用我赘述,不是SVN之流能够相提并论的. 以前多人开发的时候我还用过拖文件大发和别人合作的.- -! 我在这里不多说一些基本命令,只教最实用的,多人开发到底怎么用Git. 场景 三人合作开发一个app,老大叫小明,老二叫小强,老三叫小伟. 这时候老大去github开一个repository, 当然,公司项目一般是private repo. 创建好之后呢.老大在这个repo分别开四个分支. 名字叫 xiaoming_gi