git在公司内部的使用实践

2022-12-27 21:30:45 浏览数 (1)

搜索git使用方法是发现这篇文章,几经搜索终于找到原作者的博客,找到了原文,现在分享给大家,希望能够普及git的使用。

以下:

从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初始化工作目录。

开发工作流程:

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

常规分支debug流程

由研发经理通知相关工程师release版本x.x

代码语言:javascript复制
1. git fetch
2. git checkout -b release/x.x origin/release/x.x(拉回release版本)
3. git pull release/x.x(更新该分支)
4. 修改测试中发现的BUG
5. git push origin release/vx.x(修改完后提交分支)
6. 循环4-5

紧急debug流程

由研发经理通知相关工程师hotfix分支名称x.x.x

代码语言:javascript复制
1. git fetch
2. git checkout -b hotfix/x.x.x origin/hotfix/x.x.x(拉回hotfix分支)
3. git pull hfx.x(更新hotfix分支)
4. 在热修复分支下修改bug
5. git push origin hfx.x(修改完成,提交分支)
6. 在日常工作中不能修改master分支下得代码

研发经理

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

常规分支debug流程:

代码语言:javascript复制
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流程:

代码语言:javascript复制
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,防止代码回溯。

原作者:zeroq.me

0 人点赞