git管理工具_如何构建基于Git的开发工作流规范？Git版本管理工具应该这样用

https://github.com/GDJiaMi/frontend-standards/blob/master/development.md

版本规范

前端项目使用语义化版本进行发布:

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

1. 主版本号：当你做了不兼容的 API 修改，
2. 次版本号：当你做了向下兼容的功能性新增，
3. 修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

Git 分支模型

master分支

master分支表示一个稳定的发布版本. 对应GZB的大版本.

• 场景: 前端应用会跟随工作宝版本迭代, 在dev分支测试稳定后, 会合并到master分支, 并使用tag标记应用版本和对应的工作宝版本
• tag规范: v{APP_version}@{GZB_version}, 例如v0.1.0@GZB_6.6
• 人员: 由项目负责人进行审核合并, 普通开发者没有权限

dev分支

开发者主要工作的分支, 最新的特性或bug修复都会提交到这个分支. 开发者如果在该分支进行了提交，在push到远程之前应该先pull一下， 并尽量使用rebase模式，保证分支的简洁

• 命名规范: dev
• tag规范: 在dev分支中也可能会经历发布过程, 例如bug修复版本. 这里同样使用tag来标记这些发布. 例如v0.1.1
• 提交规范：如果是在开发分支上进行开发，在推送到远程之前，应该使用git rebase形式更新本地分支。

feature分支

涉及多人协作或者大功能的开发, 应该从dev分支checkout出独立的feature分支, 避免干扰dev分支

• 场景:
• 涉及多人协作: 团队多个成员在同一个项目下负责开发不同的功能, 这时候每个成员在自己的feature分支独立开发
• 大功能开发: 大功能开发跨越周期比较长, 需要多次迭代才会稳定. 这时候应该在独立的分支上开发. 方便跟踪历史记录, 也免于干扰dev分支的迭代和发布
• 命名规范
• feature/name: name是功能名称
• feature/GZB_version: 这也是团队常见的模式, 当无法使用一个功能名称来描述时, 可以使用GZB版本号作为’功能’
• 合并时机

1. 当feature分支迭代稳定, 并通过测试后, 合并到dev分支. 合并到dev后, feature分支的生命周期就结束了. 后续bug修复和功能优化直接在dev开发
2. 当多个feature分支需要合并对外发布临时版本时. 合并到preview分支 . 这种情况不应该合并到dev分支, 因为feature分支可能还不稳定或未完成. 比如为了联调某些功能.

• 合并方式

不要使用fast-forward. 这样可以在分支图上查看到分支历史

preview分支

临时的预览分支, preview分支用于临时合并feature分支, 这其中可能会修复某些bug或者冲突. 可以选择性地将这些提交cherrypick回feature分支. 当预览结束后就可以销毁preview分支

release分支

release分支有两种使用策略，第一种遵循gitFlow流程, 第二种是目前后端团队使用的策略，为了配合后端工作，主要使用第二种

git flow 风格的release分支

当前前端应用的稳定版本和GZB版本绑定. release分支不一定存在, 一般情况下, 只会在前端版本稳定后, 将其合并到master, 并创建tag标记. 而只有需要为指定的正式版本修复bug时才会创建release分支

• 场景: 需要为某个正式版本修复bug(hotFix)时, 从master的对应tag中checkout release分支
• 命名规范: release/{GZB_version} 外部人员只会关注GZB版本
• 如何修复
• 如果对应bug可以在dev分支直接被修复, 可以先提交到dev分支(或者已经修复了), 然后再cherrypick到release分支
• 如果bug在新版本无法复现. 比如新版本升级了依赖. 那么在release分支直接修复即可

自定义风格release分支

当要发布一个工作宝对应的版本时(或者一开始开发时)从dev分支checkout出一个开发分支，后续需要对外发布时，将dev分支合并到release分支, 并打上版本tag. 后面会介绍到后端开发和自动交付机制这种分支模式。

这一种使用策略. gzb后端在使用, 为了配合后端工作, 我们也推荐使用这种方式

• 何时创建:
• 开启GZB新版本开发任务时(推荐)
• 向外发布第一个版本时
• 何时合并：后面dev有版本发布都要合并到release分支，直到开启另一条release分支
• 好处
• 对发布内容进行筛选
• 专门用于发布, 开发者容易过滤变更的内容

提交信息规范

一个好的提交信息, 会帮助你提高项目的整体质量.

• why

1.格式统一的提交信息可以帮助自动化生成changelog

2.版本库不只是存放代码的仓库, 也记录项目的开发记录. 这些记录应该可以帮助后来者快速地学习和回顾代码. 也应该方便其他协作者review你的代码

• 原则: 半年后, 你能看懂你的commit做了什么东西
• 方式: 使用git commit(打开编辑器)而不是git commit -m
• 必要信息

1.为什么进行这次提交?

a.提交改变了什么, 让其他reviewer更容易审核代码和忽略无关的改变

2.如何解决的问题?

a.问题是什么导致的？

b.简短说明使用什么方式, 策略, 修复了问题.

3.变化可能影响哪些地方

a.说明变动功能的细节。 一个提交不应该做超过2个功能的变动

格式

BUG 处理规则

对于测试，目前会经历两个阶段

• 冒烟测试：在对测试正式发版之前会要求对代码进行自测，及冒烟测试。
• 正式测试阶段：正式测试阶段测试人员会在RDMS进行bug提交和管理，对BUG的处理规则如下：
• [解决待关闭]: 修改了程序代码, 问题解决;
• [不做处理]: 没有修改程序代码, 是由于其他原因(需求变更等), 而解决的问题;
• [退回]: 无规律或只出现一次的BUG, 研发没找到原因, 加上必要排查日志后, 可退回给测试; 复现后重新打开
• [正在处理]: 已大致定位原因, 需要较多时间处理的BUG, 可置为"正在处理"

如何处理定制化需求

痛点

对于定制化需求, 并不会引入到正规的代码流中, 一般情况下会checkout出一个分支, 来专门做这里定制化需求, 然后单独发版. 使用分支模式的缺点有:

1.更新问题

2.每次正规代码更新都要合并到该分支. 当分支较多时分支图就会比较混乱

3.正规代码合并是必然会带来风险的, 比如项目结构变动, 依赖库变动. 都可能导致定制化的代码失效

解决办法

减少代码耦合

1.尽量将定制化需求模块化, 最小化和正规代码之间的接触面. 这是解决该问题最根本的方式.

2.检验方式是结构变化时, 没有或很少适配代码

考虑通过代码层面区分

1.例如通过权限系统来配置. 通过后端接口动态配置

优先使用fork模式

1.有些场景确实无法通过代码层面解决, 比如ios应用定制启动图, icon, 应用名称, 外观等等. 这种方式优先使用fork模式, fork模式和分支模式没本质区别, 但是至少可以避免干扰正规开发流程

发布工作流

流程

1. 进行代码变更
2. 提交这些变更, 进行CI让这些变更通过测试

• 如果没通过就打tag, 一旦出现测试失败, tag就得重新打

3.提升package.json的版本号, 更新CHANGELOG.md

4.打上tag, 提交

5.可选. 合并到release分支

工具

使用jm-deploy release自动化发布并生成CHANGELOG.md

持续集成

前端项目基于公司内部部署的gitlab-ci来进行持续部署。包含以下阶段(stage):

持续集成阶段

检查： 包括单元测试和代码lint。

• 所有push到版本库的代码都会跑这个阶段. 可以在提交title中包含[ci skip]来跳过这个阶段

构建: 对前端项目进行构建.

• 只有打上版本tag的提交或release分支会跑构建任务

发布: 将前端的构建结果进行交付/发布

• 只有打上版本tag的提交或者release分支会跑发布任务. 详见jm-deploy

版本类型

根据交付或部署的环境， 可以分为以下类型：

1.preview: 临时版本. 用于预览和调试. 主要在联调环境使用. 形式为:

• v{VERSION}-preview

2.test 可交付版本. 这个版本用于交付到stage或者测试环境. 形式为:

• v{VERSION}

3.production 生产版本. 表示实际部署到生产环境的版本. 如果test版本测试通过, 就会成为生产版本. 这个过程是通过将dev分支合并到master分支时实现的. 形式为:

• v{VERSION}@{GZB_VERSION}

交付

目前前端资源是跟随后端Jar/War包一起部署的，通过将构建结果推送到一个’git发布版本库’的形式实现.

why

由于公司ToB业务. 部署环境差异较大, 也有可能无法连接外网. 所以没有统一/独立的部署方式和伺服服务器, 更没有CDN. 这要求我们的项目是可以独立部署, 自包含的. 前端项目不能独立存在和运行, 而是内嵌到后端项目中. 由对应后端项目来管理和伺服静态资源

方法

前端

发布版本库根据前面的版本类型可以划分为两种类型的分支

开发分支

• preview和test总是线性迭代的, 对于这个类型的发布总会推送到开发分支. 后端开发者可以通过这个分支获取到最新的可交付代码
• 命名,master, 直接使用master

发布分支

• 对于production, 会为每个release版本创建一个分支, 后续该release版本的hotFix都会提交到该分支
• 命名,release/{GZB_version}

对于跨项目的情况处理起来相对复杂. 因为各个项目之间版本不是同步的. 解决办法是：

项目之间通过目录区分和隔离

• 例如gzb-location 会推送到部署目录下的location目录

release分支从最新的开发分支中checkout出来. 这样可以保证拉取到其他未更新的项目

后端

后端项目使用git submodule的方式关联前端的发布版本库. 这也意味着, 如果发布版本库有变动, 后端开发人员需要手动更新submodule到指定提交记录.

好处

• 使用git版本库的方式可以记录发布记录
• 方便后端本地开发, 直接可以通过git工具拉取前端代码
• 方便人工干预

其他参考方案

• 使用npm管理前端发布 + HTTP下载
• 本地文件系统维护