Git在公司内部的使用规范

 

1.版本定义

版本号使用x.x.x.x进行定义.

  • 第一个x代表大版本只有在项目有重大变更时更新;
  • 第二个x保留;
  • 第三个x代表常规版本有新求会更新;
  • 第四个x代表紧急Bug修正;
    一个常见的版本号类似于:0.0.10.11

2.系统开发环境

简称全称作用
DEVDevelopment environment用于开发者调试使用
FATFeature Acceptance Test environment功能验收测试环境,用于测试环境下的软件测试者测试使用
UATUser Acceptance Test environment用户验收测试环境,用于生产环境下的软件测试者测试使用
PROProduction environment生产环境

3. 分支定义

分支名称作用
master主分支用于生产部署,最新稳定版本,一般由 release 或 hotfix 分支合并,任何情况下不允许直接在 master 分支上修改代码。
release预上线分支预上线分支,是develop与master之间的一个缓冲,始终保持与 master 分支一致,一般由 develop 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。(UAT)
hotfix紧急修复分支紧急分支,名规则为 hotfix- 开头,从master生成,bug修正后自动合并到master和develop并且生成tag;
develop测试分支功能验收测试环境,用于测试环境下的软件测试者测试使用,可根据需求大小程度确定是由 feature 分支合并,还是直接在上面开发。,FAT,如果开发工时 < 1d,直接在 develop 开发,如果开发工时 > 1d,那就需要创建分支,在分支上开发。
feature需求开发分支用于开发新需求和需要较长时间的BUG修改,(正式环境) 测试通过后,研发人员需要删除 feature- 分支。

4.Commit 日志规范

提交信息一定要认真填写!

建议参考规范:(scope):

比如:fix(首页模块):修复弹窗 JS Bug。

type 表示 动作类型,可分为:

fix:修复 xxx Bug
feat:新增 xxx 功能
test:调试 xxx 功能
style:变更 xxx 代码格式或注释
docs:变更 xxx 文档
refactor:重构 xxx 功能或方法
scope 表示 影响范围,可分为:模块、类库、方法等。

subject 表示 简短描述,最好不要超过 60 个字,如果有相关 Bug 的 Jira 号,建议在描述中加上。

5.开发工作流程:

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上进行开发

5.1.常规分支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

5.2.紧急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分支下得代码

5.3.研发经理:

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

5.3.1.常规分支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分支)

5.3.2紧急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,防止代码回溯

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页