后端知识

什么是摘樱桃？ 在分支协作中，出现以下这种情况，假设我的 main 分支只想要 feat 分支的 E 或者 F 的改动，此时就需要用到像摘樱桃一样给那几个提交摘过来（一个个小提交就像小樱桃），也就是 cherry-pick。 理解起来不难，但在实际操作中，还是有一些小问题的。我把目前摘樱桃的情况归为三类： 第一类是无冲突直接摘，例如 E 提交创建了一个新文件，这时 main 直接摘 E 过来是没问题的。 第二类是假设 F 是基于 E 的改动，但是我摘的时候，只摘了 F 过来，没有摘 E，此时摘樱桃操作会卡住。 第三类是你摘过来的提交和你本地的提交产生了冲突，此时需要解决冲突，cherry-pick 操作会卡住。 无冲突直接摘 这个没什么好说的，很简单，所以这里介绍一下几个 cherry-pick 的命令，分别是 git cherry-pick A // 只摘提交 A git cherry-pick A..B // 摘提交(A, B] git cherry-pick A^..B // 摘提交[A, B] git cherry-pick --abort // cherry-pick 操作终止，回滚 git cherry-pick --continue // 解决冲突后，cherry-pick 操作继续执行 所摘提交的依赖提交未摘 现在 feat 分支中有一个 main 分支中不存在的文件 READMEX.md，feat 中分别有两个提交，提交 A 是创建文件并写入一些内容，提交 B 是在文件中追加了一些内容。 ...

老 merge 了，但 rebase 弱的一逼，面试被问到，遂复盘 场景 小 A 在 feat1 分支开发，他肯定不能直接在 main 上做修改（为了保护项目的安全性），此时，为了防止大量的冲突，小 A 每次开发前都要拉去 main 分支的代码来看看，没啥冲突就直接合入，这样能有效避免积压大量的冲突。 此时就有问题了，git 中有两种合入代码的方式，分别是 merge 和 rebase，对应命令如下 git merge origin/main git rebase origin/main 到底用哪一个呢？小 A 挠挠头。 这里先给出一个方案，如果你是 main / master 分支的维护者，尽量使用 Merge，如果你是要维护自己的分支，可以用 Rebase，原因我们娓娓道来。 GitGraph GitGraph 是直观的 Git 多分支提交记录的展示，下面是一张示意图 在 GitGraph 中一条分叉就是一个分支，比如说上图，从 C 这个提交分出了一个 Feat 分支，也就是说，Feat 分支拥有含 C 之前的所有 Main 的提交，从 C 之后，Main 和 Feat 形同陌路。 Merge 合入 OK，我们先简单看看，基于上面这张 GitGraph，如果说在小 A 执行 merge 操作，会发什么？ 很直观，如果执行 merge，会基于 main 分支的最新提交和 feat 分支的最新提交，进行合并，然后形成一个新的提交，非常直观。 ...

在面 MoonShot 的时候被问到了这个，当时我只知道认证和鉴权的区别，第一遍听二者的英文名没听懂啥意思，然后就没答出来，我以为是什么其他的芝士点，可恶捏，我得饿补一下芝士点QAQ。 认证（Authentication） 我们常说的登录，这实际上就是认证：Authentication 的完整定义是身份认证，即系统确认你是谁的过程。其本质是用户提供某种可信凭证来证明自己的身份。 平时我们所说的 Jwt 鉴权、Cookie-Session 鉴权这些很多时候讲的就是认证。下面先简单讲讲两个基础认证的手段，后面后统一讲一些框架，比如说 SSO。 Cookie-Session Cookie 和 Session 算是认证的基本芝士了。众所周知，Http 是一个无状态的协议，想象一下，如果没有一种措施让服务器知道你是谁，就得每次操作都需要输一次账号密码了。虽然 Cookie 和 Session 不是专门为认证所打造的，但是其可以实现简单的认证。 下面是一个简单的 Cookie-Session 的图示： 过程相当的简单，这也正是 Cookie-Session 的优点所在，实现起来相当简单，同时 Session 的鉴权信息是保存在服务器上的，一般来说也比较安全，而缺点也很明显。 缺点： 天然非分布式。我们现在的服务器大多都是负载均衡的，而假设我们认证的信息被保存在了服务器 A 上，而后续请求都打到其他服务器上，其他服务器是没有对应的 SessionId 信息的，从而导致无法正常认证。要解决这个问题需要引入其他组件，比如说 Redis 等，进而增加了系统的复杂性。 前端未防护 XSS 的情况下，Cookie 可能会被盗取，从而导致安全问题。 Session 的生命周期管理复杂。一般来说，我们会给 Session 设置一个过期时间，认证时发现过期会拒绝请求，但这些过期的 Session 会造成一定的服务器压力，需要手动清理。 Jwt-Token JwtToken 全称是 Json-Web-Token，是一种无状态的认证手段。这个相较于 Cookie-Session 会更加符合“潮流”一些。我们来看看用 Jwt 是怎么做认证的。 上面就是一个完整的认证流程，从宏观上来看，似乎只是客户端携带的东西不同了。我认为最重要的不同点是服务器存储的信息粒度的变大，服务器无需再存储每个用户的信息，只需要存储一个服务或者一个业务的密钥，就能解决这个业务上所有用户的认证问题，这一个转变解决了下面这些问题： Cookie-Session 的天然不支持分布式的问题，只要一台服务器上有对应服务的密钥，那就 OK。 解决了 Session 的生命周期管理的问题，因为服务器无存储压力，服务器只需要看这个 Jwt 里包含的过期时间有没有过期。 如此完美的方案是否有问题呢？有的兄弟，有的： ...