从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初始化工作目录。
开发工作流程：
- git flow feature start xxxxx（开始新需求）
- 在feature/xxxxx分支下进行开发
- git flow feature finish xxxxx（开发完成后等待研发经理确认可以完成时执行）
- git push origin develop（发布develop分支）
- 每天工程师都需要git pull origin develop来更新develop分支，然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新
- 切记不能直接在develop上进行开发
常规分支debug流程：
- 由研发经理通知相关工程师release版本x.x
- git fetch
- git checkout -b release/x.x origin/release/x.x（拉回release版本）
- git pull release/x.x（更新该分支）
- 修改测试中发现的BUG
- git push origin release/vx.x（修改完后提交分支）
- 循环4-5
紧急debug流程：
- 由研发经理通知相关工程师hotfix分支名称x.x.x
- git fetch
- git checkout -b hotfix/x.x.x origin/hotfix/x.x.x（拉回hotfix分支）
- git pull hfx.x（更新hotfix分支）
- 在热修复分支下修改bug
- git push origin hfx.x（修改完成，提交分支）
在日常工作中不能修改master分支下得代码
研发经理：
开发和DEBUG流程同工程师流程
常规分支debug流程：
- git pull origin develop（更新develop分支为最新）
- git checkout develop（切换到develop分支）
- git flow release start x.x（生成一个release分支）
- 通知测试和相关得工程师分支名称
- git pull origin release/x.x（最终测试完成后拉回分支最新代码）
- git flow release finish x.x（最终修改和测试完成后，结束release版本以供发布）
- git push origin develo (发布最新的develop)
- git push origin master（发布最终得master分支）
紧急debug流程：
- git pull origin master（更新master分支为最新）
- git checkout master（切换到master分支）
- git flow hotfix start x.x.x（生成一个hotfix分支）
- 通知相关得工程师和测试人员hotfix分支名称
- git pull origin hotfix/x.x.x（最终测试完成后拉回分支最新代码）
- git flow hot fix finish x.x.x（最终修改和测试完成后，结束hot fix以供发布）
- git push origin master（发布最终得master分支）
在全部的流程中，工程师必须维护自己的feature分支保证代码最新，减少合并时的冲突。
研发经理必须维护release分支，将最新的hotfix都合并进去，保证代码最新，减少合并时的冲突。
在提交代码时还要注意判断对代码的修改是否是自己的，多用diff工具，多查看log，防止代码回溯
转载自: http://zeroq.me/p/451 作者: zeroq
扫一扫
643
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
