git在公司内部的使用实践(转)

时间：2023-01-15 23:14:25

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

从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，防止代码回溯

标签：git 使用实践

相关文章

