前端 Git 使用约定

背景

开发前端项目，有以下困惑：

使用哪个分支开发，哪个分支发布
修复线上bug的流程是什么，如何避免修复完了下次却又出现了
cms分支有十多个，是否都有用
如何快速找到之前某次功能开发，或某次bug修复

为了减轻上述困扰，引入 gitflow 规范，并根据公司情况做适当调整。

gitflow

GitFlow 是一种基于 Git 的工作流程设计，它是由 Vincent Driessen 在2010年提出的。是一种分支管理模型。请看下图：

从右往左一共5个分支。

首先是 master 主分支，也就是线上代码。不应该直接修改，只需要合并其他分支。

其次是 develop 开发分支，从master拉取，也不应该直接修改。

现在有两个版本的需求需要开发，一个是下一个版本 1.0 的（Major feature for next release）的需求，另一个是下下个版本2.0（Feautre for future release）的需求，时间更长。所以直接从 develop 分支拉取两个 feature 功能分支。

其他人也在持续的推进 develop 分支的前进

现在 1.0 的需求开发完成，于是将 feature 分支合并到 develop 中，然后从 develop 中拉取一个 release 分支，用于发布前的测试，这个 release 分支就不在开发新功能，只做bug修复（Only bugfixes），同时修复的bug也需要同步到 develop 分支，最后测试通过，则将 release 分支合并到 master 分支，同时将 release 分支合并到 develop。

线上有了问题，需要紧急处理，于是从 master 拉取 hotfixes 分支，修复完成后将 hotfixes 合并到 master 分支和 develop 分支，避免后续 develop 还有这个问题。

其中 master 分支和 develop 分支是一直存在的，其他分支都是临时的。master 分支用于存放稳定的生产版本代码，而 develop 分支则用于集成各个功能分支最新的开发成果。

分支和环境对应关系：

feature	develop	release	hotfix	master
开发环境	测试环境	预发布环境	线上	线上

分支流程：

feature -> develop -> release -> master

小建议

保持 develop 分支和 feature 分支同步：如果 develop 变动比较频繁，建议每天上班就将 develop 分支合并到 feature，这样避免两个分支差别太大，造成 feature 不能合并到 develop分支，或者需要很长时间解决冲突。
feature 分支也要时刻提交代码。万一机器坏了...

提交信息规范

Conventional Commits 是一种提交消息的规范格式

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

例如：

/*

<类型>[可选的作用域]: <描述>

*/

feat(login): add login form validation

/*

<类型>[可选的作用域]: <描述>

[可选的正文]

*/

fix(注册): 修复用户注册时的验证逻辑错误

之前的逻辑判断漏掉了对用户名长度的限制，导致用户可以注册过长的用户名，现在已经修复了该问题，并增加了相应的验证逻辑。

修复了一个潜在的安全漏洞。

/*

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

*/

feat(auth): 增加JWT认证

- 实现 JWT 生成和验证

- 更新认证中间件

关闭问题 #12345

类型有如下：

feat：表示引入新的功能（feature）的提交，即添加新的功能特性。
fix：表示修复 bug 的提交，用于修正代码中的错误或问题。
docs：表示文档变更的提交，指示与文档相关的修改，比如更新文档或注释。
style：表示代码样式（style）的修改，通常是不影响代码含义的调整，比如空格、格式化等。
refactor：表示重构代码的提交，即对现有代码结构进行非修复性的修改。
test：表示增加或修改测试的提交，用来新增或调整单元测试、集成测试等测试代码。
chore：表示其他零碎的提交，通常包括构建工具、辅助工具等的修改，比如更新构建脚本、任务管理等。
perf: 性能提升

示例如下：

feat: 添加用户管理模块

fix: 修复用户登录时的密码验证问题

docs: 更新安装指南

style: 格式化用户信息显示界面

refactor: 重构用户信息存储逻辑

test: 添加用户注册模块的单元测试

CMS改造

以CMS为例，常用的分支需要三种：开发分支、预发布分支、master分支。将其重命名并与jenkins同步。具体操作如下：

CMS目前有 4 个分支：

PS ChinaEdu-H5> git branch -r

  origin/HEAD -> origin/cms_master

  origin/test2

  origin/cms_master

  origin/cms_pre

  origin/cms_test

将分支重命名，分支和环境的对应关系如下：

// 将 test2 分支重命名 develop，对应测试环境

test2        -> develop   对应测试环境

cms_pre      -> release   对应预发布环境

cms_master   -> master    对应线上环境

例如将 test2 重命名为 develop:

$ /cms (test2)

$ git pull

Already up to date.

$ /cms (test2)

$ git branch -m test2 develop

$ /cms (develop)

$ git push -u origin :test2 develop

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0

remote:

remote: To create a merge request for develop, visit:

remote:   https://gitlab.xx.com/cms-ui/...

remote:

To https://gitlab.xx.com/cms-ui.git

 - [deleted]           test2

 * [new branch]        develop -> develop

Branch 'develop' set up to track remote branch 'develop' from 'origin'.

另外两个分支也类似。

修改 jenkins 的配置:

cms-test-pipeline-ui 构建的分支从 test2 改为 develop
cms-master-pipeline-ui 构建的分支为从 cms_pre 改为 release

修改分支下的Jenkinsfile文件：

修改 develop 分支中 Jenkinsfile 中的 def GIT_BRANCH = "develop"
修改 release 分支中 Jenkinsfile 中的 def GIT_BRANCH = "release"

Tip：由于每个分支下的 cicd 中的内容可能不同，这里使用 .gitattributes。比如有一个文件 Dockerfile，在两个分支中它是不同的，合并时不想弄乱，可以这么做：

在根目录下创建 .gitattibutes 文件，并设置内容 Dockerfile merge=ours
设置git merge的配置项 git config --global merge.ours.driver true

当你合并其他分支时，如果生效，在命令行中会显示：

$ git checkout branchA

$ git merge branchB

Auto-merging Dockerfile

Merge made by recursive.

Tip：需要注意的是，gitattribute 方法生效是有条件的，跟文件的修改时间顺序有关系。比如在 pre 分支中合并 develop，如果不想 pre 分支中 Dockerfile 被覆盖，需要 pre 中的 Dockerfile 更新，也就是要比 develop 中的 Dockerfile 修改时间更加接近现在。

Q/A

问：使用哪个分支开发，哪个分支发布

答：从 develop 分支拉取 feature 分支进行开发，用 release 分支预发布，用 master 发布。

问：修复线上bug的流程是什么，如何避免修复完了下次却又出现了

答：直接从master分支拉取 hotfixes 分支开发，然后合并到 develop 分支到测试环境测试，如果紧急则直接合并到 release，在预发布测试通过后合并到 master，最后不要忘记合并到 develop

问：cms分支有十多个，是否都有用

答：没有用的分支尽快删除

问：如何快速找到之前某次功能开发，或某次bug修复

答：使用Conventional Commits提交规范

问：dist 需要提交吗？

答：不需要，jenkins 会自己构建。