专栏首页程序生涯Git在公司内部的使用规范

Git在公司内部的使用规范

1.版本定义

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

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

2.系统开发环境

简称

全称

作用

DEV

Development environment

用于开发者调试使用

FAT

Feature Acceptance Test environment

功能验收测试环境,用于测试环境下的软件测试者测试使用

UAT

User Acceptance Test environment

用户验收测试环境,用于生产环境下的软件测试者测试使用

PRO

Production 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,防止代码回溯

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • /bin,/sbin,/usr/sbin,/usr/bin 目录之简单区别

    从命令功能来看,/sbin 下的命令属于基本的系统命令,如shutdown,reboot,用于启动系统,修复系统,/bin下存放一些普通的基本命令,如l...

    用户7657330
  • IPV6

    在企业内部,IP冲突问题已不是新鲜话题,在区域之间,IP地址有限可能带来了安全隐忧或影响了冲浪速度;在更高层面,地址不足甚至严重制约了一个国家互联网的应用和发展...

    用户7657330
  • HTTP使用BASIC认证的原理及实现方法

    在HTTP协议进行通信的过程中,HTTP协议定义了基本认证过程以允许HTTP服务器对WEB浏览器进行用户身份证的方法,当一个客户端向HTTP服务 器进行数据请求...

    用户7657330
  • gitflow 开发流程学习(第二部分)

    前端正义联盟
  • Git基础和规范-协同开发

    关于版本控制 什么是版本控制: 官方说法:版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统,你可以对任何类型的文件进行版本控制。 ...

    用户1257215
  • 带领前端小伙伴重温「Git Flow Workflow」

    关于Git Flow 工作流,我想已经是老生常谈的话题了,但是今天我不得不来重温一下 Git Flow 工作流。当我看的代码厂库的时候,我已经开始怀疑人生。乱七...

    拾贰
  • 如何用Github的gh-pages分支展示自己的项目

    很多新同学觉得github不就是一个代码托管所吗,如何能展示项目呢?其实完全可以借助Github的gh-pages打造出自己的一个作品集,无论是对自己的提升整合...

    牧云云
  • 可视化专家教你如何让数据栩栩如生

    ? 数据可视化,数据是本质。 其产生与兴起,一方面是由于人们有着对数据的各种对比、趋势、关联等等的诉求;另外一方面,人是视觉动物,对于大量的原始数据不敏感,...

    腾讯NEXT学位
  • 日志清理脚本-V0.0.3(增加多目录清理、正则表达式匹配、调试模式;部分细节优化)

    解决某些中间件或者应用日志无法自动清理的情况,比如:Nacos 的 access 日志清理,临时目录文件清理等。

    叨叨软件测试
  • 【知识科普】安全测试OWASP ZAP简介

    开放式Web应用程序安全项目(OWASP,Open Web Application Security Project)是一个组织,它提供有关计算机和互联网应用程...

    嘉为科技

扫码关注云+社区

领取腾讯云代金券