2024年最全摸索前端管理2年，这份研发流程帮到我不少(1)，2024年最新面试题目-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84435555/article/details/138865712

结尾

正式学习前端大概 3 年多了，很早就想整理这个书单了，因为常常会有朋友问，前端该如何学习，学习前端该看哪些书，我就讲讲我学习的道路中看的一些书，虽然整理的书不多，但是每一本都是那种看一本就秒不绝口的感觉。

以下大部分是我看过的，或者说身边的人推荐的书籍，每一本我都有些相关的推荐语，如果你有看到更好的书欢迎推荐呀。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

前端学习书籍导图-1

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 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。然后本地进行分支操作。

git checkout develop

git pull

git branch -d issue/1

git checkout -b issue/1

继续开发…

开发到中途想拉别人代码

如果自己正在 issue/1 分支开发，而其他同事提交了代码，并且已经合并到 develop 分支，此时你想用他这部分代码。需要执行以下步骤。

git checkout develop // 如果这一步如果无法执行，见下一节

git pull

git checkout issue/1

git merge develop

想切出去合入别人提交的最新代码却发现git checkout develop报错

这种情况是因为你的 issue 分支代码与最新的 develop 分支相比，已经落后或者产生了冲突。

此时如果仍希望把别人提交的最新代码合入到自己的 issue 分支继续开发，需要执行以下步骤，利用git stash做一个临时储存。

// 假设现在位于 issue/1 分支

git stash

git checkout develop

git pull

git checkout issue/1

git merge develop

git stash pop

此时一般会出现冲突，VSCode git 区域会有提示感叹号或者 C（代表 conflict）。

需要解决掉冲突再继续开发，开发完毕后按正常流程提交代码。

其他

以上是以新特性开发为例进行说明。

其实对于修复缺陷而言，整个操作流程也基本相同。

如果是测试环境和生产环境都有的bug，通常先修复测试环境验证效果后，视情况通过 cherry-pick 进行生产环境紧急发版。紧急情况下，可优先修复生产环境。

issue和merge request规范

issue规范

创建 issue 时，应清楚该 issue 用于处理什么事务。

如果明确 issue 处理的是 TAPD 上的需求或缺陷，必须在描述中插入 TAPD 链接，方便自己或同事查阅跟踪。选择的 Label 应该是需求或 Bug。

如果不是来源于TAPD，则在标题中简要说明主题，在描述中说明具体事项（可选），根据实际情况选择合适的Label。

Merge Request 规范

提交 Merge Request 时，应明确目标分支。比如需求类的，我们是基于 develop 分支创建 issue/xxx 分支，所以提交到远程同名分支后，需要请求合入到 develop 分支。
对于 bug，首先明确 bug 发生的环境。而对于生产环境bug，我们是基于 master 分支创建 issue/xxx 分支，解决完之后，是请求合入到 master 分支；测试环境bug的处理方式可类比；如果一个bug在开发环境，测试环境和生产环境都有出现，应基于develop分支新建分支，bug 处理完毕后先发起 MR 合入到 develop 分支，再通过 cherry-pick 等方式合入到 release 或者 master 分支。

可能有人会觉得生产环境 bug 相关的代码直接合入到 master 分支不妥，这个我觉得可以看具体情况分析，如果团队的风险把控程度严一点，可以考虑安排一个预发布分支，对应一个预发布环境，尽可能模拟生产环境。

Assignee选择审核人，一般是Mentor或其他同事（交叉评审）。

同时也附上Labels，表明你这次提交解决了哪些类型的问题。如同时涉及多类，则进行多选。比如，我同时解决了 bug 和需求，那我就会勾选两项，但是不推荐这样做，因为我们建议一个 issue 只做一件事，所以一次 Merge Request 也意味着只解决一个问题。
如果涉及发版分支（比如release和master），建议勾选下环境选项（如测试环境，生产环境），给人一目了然的感觉。