最后
由于篇幅限制,pdf文档的详解资料太全面,细节内容实在太多啦,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
-
源码仓库:自建
Gitlab
-
团队文档:语雀
处理IconFont图标
在图标管理这块,我们使用的是 iconfont,包括字体图标和矢量图标都有用到,并且封装了对应的组件icon-font
和icon-svg
,目前主要以使用icon-svg
为主,icon-font
主要面向部分项目。
在 iconfont 上调整好图标后,需要重新生成链接;
- 对于字体图标组件 icon-font,生成在线的 font class 链接,替换掉项目中 index.html 中的对应链接才会生效。
- 对于矢量图标组件 icon-svg,生成在线的 symbol 链接,替换掉 icon-svg 组件中引用的 js 链接才会生效。
issue驱动
虽然git log
已经提供了记录查询的能力,但是还不够便捷,直观。
我们采用issue
驱动开发,所有的代码改动都应该先在gitlab
创建issue
,包括但不限于需求,缺陷,自测试,优化类改动。
commit是可以自动关联和关闭issue的,这样一来,我打开每一个issue,就知道这个issue关联了哪些代码提交记录,查问题非常直观!另外,这也是众多开源项目常见的协作方式。
对于需求、缺陷类型的开发任务,应在创建issue
时附上TPAD
相关链接,方便跳转查询。
issue应该保证原子性,一个issue只做一件事。
开发流程
VSCode扩展
首先,安装必要的 VSCode 扩展,结合项目中配置的 Lint/Formatting 能力,达到一个高效开发的状态。
全局依赖
// 保证 yarn 的正常使用
npm install -g yarn
// 用于规范 commit 提交
npm install -g commitizen
npm install -g conventional-changelog-cli
npm/yarn代理
npm 自带的源有时候速度太慢,或者有时候根本下载不了某个包,容易导致 install 失败或停顿,请统一使用 taobao 代理。
npm config set registry https://registry.npm.taobao.org
// 部分项目使用yarn
yarn config set registry https://registry.npm.taobao.org
Nginx代理配置
我们在开发者本地使用 Nginx 作为中间代理,加一层本地 Nginx 代理的目的是:
-
统一项目访问的服务端口,防止误提交项目配置文件,避免不必要的代码冲突。
-
便于切换不同环境时,实现秒级切换,不用重启 devServer。后面这里可以优化下,据我观察,ant-design-pro 实现了不重启 devServer 更新 proxy,有空研究下!
-
如果比较反感,不强制增加本地 Nginx 这一层,可以自行指定后端 gateway 地址,但是注意不要提交 vue.config.js 文件,避免引起冲突!
- 下载windows稳定版本Nginx,链接是http://nginx.org/en/download.html[2]
- 修改nginx/conf/nginx.conf
一个基本的代理配置如下:
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
#gzip on;
server {
listen 8090;
server_name 127.0.0.1;
location / {
proxy_pass http://xxx.xxx.tech;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
nginx 统一监听 127.0.0.1:port,代理请求到后端 gateway。在需要切换环境时只需要修改 proxy_pass 这一项即可。
-
前端工程默认配置 proxy 的 target 为
http://127.0.0.1:port
,配合Nginx使用时,不要修改此项。 -
常见命令
#linux中
#开机启动
systemctl enable nginx
#启动
systemctl start nginx
#重启
nginx -s reload
#windows中
#启动
直接打开nginx.exe
#重启
修改配置文件后重启,可以选择cmd打开根目录,然后nginx.exe -s reload
#其他
如果重启有问题,一般是点击了多次nginx.exe,这时候可能启动了多个nginx,算是个windows版本的bug吧,
可以直接打开任务管理器找到所有nginx进程,然后结束掉。最后直接打开nginx.exe启动。
关于这一环节,我之前还写过一篇「前端必看」这篇Nginx反向代理技巧,助你准时下班陪女神,想要详细了解的朋友可以打开看看。
项目依赖安装
目前有的项目使用npm
管理依赖,有的使用的是yarn
。进入项目时,观察lock
文件,如果项目根目录有yarn.lock
,则说明使用yarn
;如果项目有package-lock.json
,说明使用npm
。
安装依赖时根据情况执行以下命令:
- npm
npm install
- yarn
yarn
需求/缺陷分配
TL负责任务分配,将TPAD
上的需求进行分配,指定开发责任人。
TAPD的需求分发到个人后,都要求开发人员拆分出前端子需求(不限于1个),根据自身能力和需求复杂度评估出开发时间规模,根据自己的排期填写预估起始时间和结束时间,项目经理会追这个事情,责任到个人。如果有逾期风险,提前向 TL 或者自己的导师反馈原因,不要拖到最后一天才暴露问题。
按道理,开发时间规模应该是大家做需求评审时定下来的,但是考虑到团队的一个实际情况,这块权限是下放到开发者自行评估,但是 TL 需要起到一个监督的作用。这里大家可以结合实际情况考量。
创建issue
原则上由开发者自行创建,创建需求和 bug 类 issue 时,应附上 tapd 链接,方便查询关联事项!issue 也是分支命名的一个依据。下面我会接着说。
有些时候,TL 或者项目 Owner 会安排一些非 TAPD 管理的组内任务,会直接以 issue 形式指给开发人员,开发人员接到 issue 后,不必再重复创建 issue,只要基于已创建的 issue 创建本地分支开发就行。
分支权限控制
在我们团队中,约定了三个重要分支,分别是:
-
develop:开发分支
-
release:测试分支
-
master:生产分支
这三个分支被设置为 Protected Branches,通常都关联了对应环境的 CI/CD 配置。在权限控制上一般设置为:Maintainer 拥有 Merge 权限,所有人都没有 push 权限。
实际操作时,一个基本的 Merge 方向是:
根据实际情况,也可以引入预发布分支之类的分支。
如果对分支权限不做控制,大家可以随意 push,就意味着潜在的灾难随时可能发生。所以这一点是非常值得关注的!
创建分支
我之前也试过分支语义化命名,但是也发现了要用有限的单词描绘出复杂的含义永远是个伪命题。我们可能会在做一个新功能时,会把相关分支命名为feature/xxx
,而后面有优化类需求时,又会新建一个feature/xxx-optimization
之类的分支。然而,往往一个功能会有一次又一次的优化、变更或 bug,采取这样的命名策略永远会让自己直面灵魂拷问!
并且在追溯问题时,这种分支命名方式往往让人心力交瘁!
那么如何命名能解决这样的问题呢?我采用了下面这种策略!
issue
本身有一个编号,或者叫ID
,这种唯一标识让我们命名分支变得简单。假定一个issue
的编号是1
,那么我们在本地创建分支时,只需要将分支命名为issue/1
即可,根据这个编号,我就能查到这个分支处理的是哪个issue
,而打开 Gitlab 的issue
界面,我就能知道这个issue
与什么需求或缺陷有关,而且也能直观看到与这个issue
关联的代码 commit 记录。这不仅给开发者带来了方便,也让管理者变得更轻松!
好,下面说实际操作。以开发新特性为例:
- 本地切换到
develop
分支,拉取最新develop
分支代码
git checkout develop
git pull
- 基于
develop
分支创建新的特性分支,用于开发新特性,目前统一命名为issue/xxx
,其中xxx
是你在gitlab
上创建的issue
号,如下所示:
git checkout -b issue/1
也就是说,issue/1
分支用于解决gitlab
上的issue 1
提到的问题。
有的项目比较简单,或者还在初期阶段,这种情况下,不会设置 develop 分支,而是基于 master 分支快速开发。如果是这种情况,在上面的操作中,可以直接把 master 理解为 develop,依葫芦画瓢即可。
提交代码
特性/缺陷分支应该保证原子性,一个分支只解决一个问题(指的是一个issue提及的问题),否则原则上不允许合入其他分支。这对敏捷迭代有关键意义!
开发完毕后,应提交到远程仓库同名分支。
git add .
git cz // 进行cz交互式命名行提交
git push origin HEAD // 提交到远程仓库同名分支
提交部分代码
如果一次commit希望提交部分文件(而不是全部修改的文件),不要用 git add .
,可以结合 GUI 进行选择(比如VSCode自带的Git面板),进入staged状态的文件,就是你希望提交的。
➕ 是进入 staged,➖ 是移出 staged,Staged Changes 就是你希望在这次 commit 的内容。
提交部分代码时,注意保管好自己未提交的代码,未入库就有丢失的可能,这一点要明确!
git cz流程
git cz
是commitizen
提供的能力,这块我之前简单写过一段介绍,具体见规范commit message[3]。使用git cz
的主要目的就是规范代码提交。
-
选择提交的类型,
feat
代表需求,fix
代表修复缺陷,docs
代表文档类变动,style
是代码风格层面的(不是指样式…),refactor
指的是代码重构,perf
则是优化相关的(包括性能/体验等),test
是单元测试之类的,build
是构建工具相关的,ci
是持续集成相关的,chore
的解释各异,按commitizen
的解释就是非src
或test
的其他改动,revert
代表代码回退… -
请准确选择改动类型!
- 影响范围
【按情况填写即可,如果不是过于抠细节,大部分时候可以不填】
What is the scope of this change (e.g. component or file name): (press enter to skip)
- 改动描述
【必填】本次代码改动的描述信息,可摘取issue的标题,或者是tapd需求或缺陷的标题,也可以自行总结。
Write a short, imperative tense description of the change (max 94 chars):
登录功能开发
- 详细描述
【按情况填写,如果不是过于抠细节,大部分时候可以不填】提供详细描述
Provide a longer description of the change: (press enter to skip)
- 是否有重大变更?
【一般是回车或者输入N跳过】一般来说,只有架构层面的变更才会填入y
Are there any breaking changes? (y/N)
- 是否影响issue?
【一般来说,一次commit都应该有与之关联的issue,输入y,用来关闭issue,这个是很常见的】
Does this change affect any open issues? (y/N)
【一般可以跳过】如果关联的issue已经关闭,可以针对本次commit 做一个信息补充。
If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:
(-)
- 关闭issue?
? Add issue references (e.g. “fix #123”, “re #123”.):
假设要关闭 issue#1,则输入:
fix #1
如果要关闭多个 issue,则输入:
fix #1 #2 #3
- 提交至远程同名分支
git push origin HEAD // 提交到远程仓库同名分支
commit 检查
配合 husky 和 git hook 来实现 commit 检查。
-
防止提交不符合规范的代码。
-
防止
commit message
不规范。
这里需要借助以下依赖:
-
husky
-
commitlint
-
commitizen
-
conventional-changelog-cli
-
lint-staged
发起Merge Request
git push
到远程同名分支后,并不代表你的代码进入了主分支,你接着还需要走代码合并流程。
由开发者在gitlab
自行发起Merge Request
,请求将代码合入develop
分支。
TL或者有Merge权限的人负责进行Code Review,审核通过后,方可合入代码。
本地获取最新develop分支
代码合入后,就可以基于develop
分支做其他的功能开发了。
git checkout develop
git pull
// 进行其他的特性开发,或bug修复
继续未完成的需求
如果提交代码并被Merge后,发现本需求并未开发完毕,此时不可再另外创建 issue,应该基于同一个 issue 继续修改;以 issue 号为 1 举例说明。
首先需要在 gitlab 上 reopen issue#1。然后本地进行分支操作。
最后
由于篇幅限制,pdf文档的详解资料太全面,细节内容实在太多啦,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
conventional-changelog-cli
- lint-staged
发起Merge Request
git push
到远程同名分支后,并不代表你的代码进入了主分支,你接着还需要走代码合并流程。
由开发者在gitlab
自行发起Merge Request
,请求将代码合入develop
分支。
TL或者有Merge权限的人负责进行Code Review,审核通过后,方可合入代码。
本地获取最新develop分支
代码合入后,就可以基于develop
分支做其他的功能开发了。
git checkout develop
git pull
// 进行其他的特性开发,或bug修复
继续未完成的需求
如果提交代码并被Merge后,发现本需求并未开发完毕,此时不可再另外创建 issue,应该基于同一个 issue 继续修改;以 issue 号为 1 举例说明。
首先需要在 gitlab 上 reopen issue#1。然后本地进行分支操作。
最后
由于篇幅限制,pdf文档的详解资料太全面,细节内容实在太多啦,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
[外链图片转存中…(img-f6qZkw4l-1715636695534)]
[外链图片转存中…(img-0tkMlIuQ-1715636695535)]