从2011.10月左右,开始在后台组推行git版本控制,到现在也差不多半年了,也形成了一套基于git flow的副官模式工作流程:

版本定义:

版本号使用x.x.x进行定义,第一个x代表大版本只有在项目有重大变更时更新
第二个x代表常规版本有新需求会更新
第三个x代表紧急BUG修正
一个常见的版本号类似于:0.11.10


分支定义:

  • master分支对应线上版本,上线都使用master;
  • develop是开发分支,用于生成提测分支release,始终保持最新;
  • hotfix是紧急分支,从master生成,bug修正后自动合并到master和develop并且生成tag;
  • feature是私有分支,用于开发新需求和需要较长时间的BUG修改
  • release是提测分支也即常规分支,测试并且bug修改结束后生成该版本tag,后续可以使用git show tagname来查看版本信息或者回滚


工程师:
 clone版本库后,首先git flow init初始化工作目录。

  开发工作流程:

  1. git flow feature start xxxxx(开始新需求)
  2. 在feature/xxxxx分支下进行开发
  3. git flow feature finish xxxxx(开发完成后等待研发经理确认可以完成时执行)
  4. git push origin develop(发布develop分支)
  • 每天工程师都需要git pull origin develop来更新develop分支,然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新
  • 切记不能直接在develop上进行开发


  常规分支debug流程:

  1. 由研发经理通知相关工程师release版本x.x
  2. git fetch
  3. git checkout -b release/x.x origin/release/x.x(拉回release版本)
  4. git pull release/x.x(更新该分支)
  5. 修改测试中发现的BUG
  6. git push origin release/vx.x(修改完后提交分支)
  7. 循环4-5

  紧急debug流程:

  1. 由研发经理通知相关工程师hotfix分支名称x.x.x
  2. git fetch
  3. git checkout -b hotfix/x.x.x origin/hotfix/x.x.x(拉回hotfix分支)
  4. git pull hfx.x(更新hotfix分支)
  5. 在热修复分支下修改bug
  6. git push origin hfx.x(修改完成,提交分支)

在日常工作中不能修改master分支下得代码

 研发经理:

  开发和DEBUG流程同工程师流程 

  常规分支debug流程:

  1. git pull origin develop(更新develop分支为最新)
  2. git checkout develop(切换到develop分支)
  3. git flow release start x.x(生成一个release分支)
  4. 通知测试和相关得工程师分支名称
  5. git pull origin release/x.x(最终测试完成后拉回分支最新代码)
  6. git flow release finish x.x(最终修改和测试完成后,结束release版本以供发布)
  7. git push origin develo (发布最新的develop)
  8. git push origin master(发布最终得master分支)

  紧急debug流程:

  1. git pull origin master(更新master分支为最新)
  2. git checkout master(切换到master分支)
  3. git flow hotfix start x.x.x(生成一个hotfix分支)
  4. 通知相关得工程师和测试人员hotfix分支名称
  5. git pull origin hotfix/x.x.x(最终测试完成后拉回分支最新代码)
  6. git flow hot fix finish x.x.x(最终修改和测试完成后,结束hot fix以供发布)
  7. git push origin master(发布最终得master分支)

在全部的流程中,工程师必须维护自己的feature分支保证代码最新,减少合并时的冲突。

研发经理必须维护release分支,将最新的hotfix都合并进去,保证代码最新,减少合并时的冲突。

在提交代码时还要注意判断对代码的修改是否是自己的,多用diff工具,多查看log,防止代码回溯

转载自:  http://zeroq.me/p/451  作者: zeroq

git在公司内部的使用实践(转)的更多相关文章

  1. 【转】git在公司内部的使用实践

    版本定义: 版本号使用x.x.x进行定义,第一个x代表大版本只有在项目有重大变更时更新 第二个x代表常规版本有新需求会更新第三个x代表紧急BUG修正一个常见的版本号类似于:0.11.10 分支定义: ...

  2. Git在公司内部的使用规范

    Git在公司内部的使用规范 目录 Git在公司内部的使用规范 1.版本定义 2.系统开发环境 3. 分支定义 4.Commit 日志规范 5.开发工作流程: 5.1.常规分支debug流程: 5.2. ...

  3. 公司内部搭建git服务器

    前言 因为gitHub上的项目是公开的,不适合公司内部项目放在上面,而私人的需要收费,这绝非是我们愿意的.所以找了个跟gitHub很相似,但是又免费的gitLab.现在将搭建gitLab过程记录一下留 ...

  4. 一个老鸟发的公司内部整理的 Android 学习路线图 Markdown 版本

    jixiaohua发了一篇一个老鸟也发了一份他给公司内部小伙伴整理的路线图.另一份 Android 开发学习路线图.可惜不是MarkDown格式的,所以jixiaohua直接上传的截图,在jixiao ...

  5. WCF/WPF公司内部订餐程序开发

    WCF/WPF公司内部订餐程序开发 (服务端篇) 上班的第一天,群里讨论关于订餐的问题,所以想到了要不要自己开发一个公司内部的订餐系统呢?方便公司内部员工的订餐,有了想法就简单的实践了下 . 实现还是 ...

  6. PouchContainer 开源版本及内部版本一致性实践

    PouchContainer 开源版本及内部版本一致性实践 为什么要做内外版本一致 对外开源是提升影响力.共建生态的有力手段.在项目对外开源的过程中,首先是将可以开源的部分抽离出来,发布一个“开源版本 ...

  7. Git 在团队中的最佳实践--如何正确使用Git Flow

    我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用. Git的优点 Git的优点很多,但是这里只列出我认为 ...

  8. Rafy 领域实体框架 - 公司内部培训视频

    本月给公司内部一个项目做架构重构,其中使用到了 Rafy 框架.所以我培训了 Rafy 领域实体框架的使用方法,过程中录制了视频,方便其他同事查看.现在把视频放到园里来分享下,有兴趣的朋友可以看看,有 ...

  9. 搭建公司内部的NuGet Server

    随着公司业务慢慢的拓展,项目便会越来越来多,很多项目会依赖其他项目DLL,比如一些底层的技术框架DLL引用,还有各业务系统的也有可能会有引用的可能. 项目多,交叉引用多,如果要是有一个DLL更新,那就 ...

随机推荐

  1. hdu 1247 map的使用

    http://acm.hdu.edu.cn/showproblem.php?pid=1247 Hat’s Words Time Limit: 2000/1000 MS (Java/Others)    ...

  2. WebSphere MQ 入门指南

    WebSphere MQ 入门指南这是一篇入门指南.我们从最基本的概念说起: 基础概念 对于MQ,我们需要知道4个名词:队列管理器.队列.消息.通道:对于编程设计人员,通常更关心消息和队列,对于维护管 ...

  3. UVA 12898 - And Or 数学

    题目链接:https://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&page=show_problem ...

  4. js输出26个字母两种方法(js fromCharCode的使用)

    方法一 var character = new Array("A","B","C","D","E", ...

  5. poj1434Fill the Cisterns!(二分)

    链接 题目说给你n个水箱,初始是没有水的,每个的高低位置可能不同,给了你初始的水箱底部所处的水平线位置,问给你V体积水时,水的水平线位置. 直接二分位置p,对于每一个底部低于水平线位置的水箱,里面的水 ...

  6. mysql 锁的粒度

    1.锁的类型分为读锁和写锁,这个很好区分.可以这样认为:如果有增删改,就是写锁.如果是查询,就是读锁.2.锁的粒度也就是锁的范围,分为行锁和表锁.锁的范围和多个因素有关,包括事务隔离级别.是否使用索引 ...

  7. JavaSE复习_7 异常

    △子父类涉及的异常问题:      1.子类在覆盖方法时,父类的方法如果抛出了异常,那么子类的方法只能抛出父类的异常或者该异常的子类,且只能抛出异常的子集      2.如果父类抛出了多个异常,子类只 ...

  8. 【Todo】【读书笔记】大数据Spark企业级实战版 & Scala学习

    下了这本<大数据Spark企业级实战版>, 另外还有一本<Spark大数据处理:技术.应用与性能优化(全)> 先看前一篇. 根据书里的前言里面,对于阅读顺序的建议.先看最后的S ...

  9. 关于协程的学习 & 线程栈默认10M

    先看的这篇文章:http://blog.csdn.net/qq910894904/article/details/41699541 以nginx为代表的事件驱动的异步server正在横扫天下,那么事件 ...

  10. Android最佳性能实践(一)——合理管理内存

    有不少朋友都问过我,怎样才能写出高性能的应用程序,如何避免程序出现OOM,或者当程序内存占用过高的时候该怎么样去排查.确实,一个优秀的应用程序,不仅仅要功能完成得好,性能问题也应该处理得恰到好处.为此 ...