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流程：

由研发经理通知相关工程师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

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

5.3.研发经理：

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

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

5.3.2紧急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在公司内部的使用规范相关推荐

mysql datetime 默认值_老大让我整理下公司内部MySQL使用规范，分享给大家
作者:白程序员的自习室链接:https://www.studytime.xin/article/mysql-internal-specifications.html 最近涉及数据库相关操作较多,公司 ...
redis key命名规范_公司内部 Redis 使用规范
前言在业务中,会经常使用 Redis 作为后端缓存.存储.如果结构规划不合理.命令使用不规范,会造成系统性能达到瓶颈.活动高峰系统可用性下降,也会增大运维难度.为了避免出现因 Redis 使用不当, ...
老大让我整理下公司内部 MySQL 使用规范，分享给大家
点击上方"码农突围",马上关注这里是码农充电第一站,回复"666",获取一份专属大礼包真爱,请设置"星标"或点个"在看&quo ...
git在公司内部的使用实践(转)
从2011.10月左右,开始在后台组推行git版本控制,到现在也差不多半年了,也形成了一套基于git flow的副官模式工作流程: 版本定义: 版本号使用x.x.x进行定义,第一个x代表大版本只有在项 ...
git仓库迁移（阿里云git切换到公司内部的gitlab）
项目刚开始做的时候,因为公司内部的git服务器尚未搭建好,所以使用了阿里云git服务器,目前内部服务器已搭建好,所以git需要完整迁移(完整迁移,就是指,不仅将所有代码移植到新的仓库,而且要保留所有的 ...
一个老鸟发的公司内部整理的 Android 学习路线图 Markdown 版本
jixiaohua发了一篇一个老鸟也发了一份他给公司内部小伙伴整理的路线图.另一份 Android 开发学习路线图.可惜不是MarkDown格式的,所以jixiaohua直接上传的截图,在jixiao ...
GPS公司内部管理系统
本篇文章的目的是介绍一款软件,软件属于我的业余爱好,此软件是我从学习VB.net后的第一个软件,现在感觉VB6已经生疏了,干脆直接换成.net了,趁过渡的机会为朋友写了这个软件.如有写的不好的地方,请 ...
使用 satis 搭建一个私有的 Composer 包仓库在我们的日常php开发中可能需要使用大量的composer包，大部份都可以直接使用，但在公司内部总有一小部份包是不能公开的，这时候我们就需
使用 satis 搭建一个私有的 Composer 包仓库在我们的日常php开发中可能需要使用大量的composer包,大部份都可以直接使用,但在公司内部总有一小部份包是不能公开的,这时候我们就需要 ...
Docker搭建公司内部私有云平台 -- Gitlab
目录简介下载并配置Docker环境拉取镜像并启动Gitlab 将本地代码推送到Gitlab当中总结简介 1.什么是gitlab? web平台[网站] gitlab上存储的文件用户可以将文件 ...

Git在公司内部的使用规范