@yeqizhang 中途终止→中止

中途停止，中止。

终止<=>terminate

@justNoBody 双向 merge 的诡异之处在于，这东西会受时序影响。两个 feature 分支的分岔点如果一样，可能不会出问题，但如果一前一后各自分岔，那么 A=>B=>C 与 B=>A=>C 的结果可能就不一样而且不符合预期了。

你也许没明白的是，双向 merge 会发生未产生冲突就丢代码的情况。

原因是更新（ new ）的节点(A)merge 了一个旧节点(B)再 merge 回去(B') 会使 B'认为「不存在(B~B)'期间提交历史」的版本更新（ newer ），从而丢弃(B~B')。这个情况是很难预期也不好发现的。

所以实践上应该禁止 feature2 去 merge dev ，它完全可以 rebase dev 把自己接到后面，此时解决冲突相当于相当于不断发生 dev[N],dev[N+1],feature2[N+1]的三路合并，由于 base 点在 dev[N]，所以不会丢失 dev[N]后的东西（不会认为 dev[N]前的版本更新(newer)），又因为 N 必定大于 feature1 与 dev 的分岔点（ feature1 已经接到 dev 上了），所以也不会丢失 feature1 上的东西。

-----

我看很多人在说解决冲突时误删了代码，然而并不是这么回事。更要命的是搞清并向每一个人说明原理实在是太难了。所以直接制定规则是最可靠科学的办法

1. 你自己没试过对自己有没有用，说明你不是在强行把自己的感受加给别人
2. 有两种实验结论，说明这东西很可能因而而异，但你又不想承认因人而异

那你就是想把一部分人的感受强加在另一部分人身上，然后这两部分人是什么感受，你自己都没亲自实践感受过……


不是，那你图啥？

https://www.jianshu.com/p/603186352605

严禁双向 merge. 3B 做了一个从其它分支 merge 的操作，万恶之源。


虽然
https://i.imgur.com/MooCOTd.png

但是还是强烈建议你们设定「严禁自己分支 merge 其它分支」的规则。
要临时合并其他人的工作只允许 rebase/cherry-pick ，

严禁双向 merge.

有没有一种可能：

@billytom
首先马车帆船出行完全可行，是个可供开拓的市场，只是开拓这个成本要耗费的精力和成本十分高昂，短时间内你熟悉的企业没有碰。

第二非智能手机直到今天也仍有需求，在购物网站上你也能很容易通过搜索条件真的找到这些产品，跟无法选择电 /油车的情况根本不一样

总而言之你举得两个类比都不恰当。

------

打车租车都是租赁机动车出行，租车理所当然地提供了品牌车型选项，而打车无论什么价位和服务品牌，都没有做垂直划分，反而是非常奇怪的。现在这些服务平台只聚合，聚合了资源又不针对性投放，属实搞不懂不做这个的原因。只能猜测是调研过不可能做得起来，成本或政策铁拳

> 那也就是说，没有太好的解决方法咯，那实际开发中，如果碰到不熟悉的库，有什么方便开发的优解
没有。

有的库会提供 stub file 专门用来注解 type hint, 但基本还是只能翻文档

https://i.imgur.com/JHAr8De.png
https://i.imgur.com/NiYkLRE.png

如图

一开始还以为「做贡献」是说教点什么，然后仔细一看原来贡献是指做辅助工具……
这。。。


要不你先给他做个「今天吃什么」——不对，「这个这个学期买什么」，试探一下反馈？

@acbot 不要拿你后端的思维去看前端。。

1. 你写的 APerfectConceptType a_perfect_named_var 最后也会被编译器处理，或混淆或丑化或 mangle ，你永远不需要关心也不应该关心你源码里写的变量名变成了什么，正如你不需要关心打包后名字变成了什么一样。后端语言有 source map ，把编译结果映射回源码里的行号，前端一样有。

2. 前端 app 是个可随时热更新的单页面，热更新要替换加载新文件，后端实现热更新可能 diff 的是文件 hash 、文件头签名，但前端在准备更新时新旧文件处于网络的两端，diff 文件内容成本昂贵，所以能比较容易 diff 的就是文件名或者说版本标识号。

3. 使用 vite ，版本滚动的次数=你编辑焦点离开文件的次数，自动随机标识号就理所当然天经地义了。



另外 前端技术的过期时间普遍小于两年，如果你对找到的教程内容有异议，先找找这篇东西的**原始作者**的发布时间。2020 年前的别看。

@L4Linux
@wdhwg001

乍一看没什么特别的，但这不是 consteval 函数，是 coroutine.
想象一下有栈协程和动态类型的解释型语言此时在干什么（看向 v8 ）。
能把并发函数优化成常量说明这个「协程」甚至不是状态机（编译器很难优化状态机），而是直接计算了 cps 变换后的结果，这就很 amazing 了。


可以看看 cppcon2016 的那个视频，当你先写了一段 sequential 代码，再改成异步，再改成 coroutine ，再把优化一开
——
boom ，一个常数！

跟魔术一样，performance makes a trick being real magic.

从 ppt 和我一点实验来看，现在的基础设施还不能把 coroutine 优化得特别好，起码还没达到 presentation 展示的最佳效果，标准库也还没跟上。等标准库完善之后编译器应该能更好地优化，从 presentation 来看，能优化的东西是有很多而且很有效的，未来可期。（指 c++26 以后）

合理，但你举得例子不太合理。

首先不是所有的岗位需要掌握的基础知识都一样，除非你想考察的基础知识就是算法，那另说。

进制转换这种教科书第一章第一节的示例题，答出来也说明不了什么，也不是个好的展开点。你也许想考察 CPU 相关的知识或者浮点或者格式化字符串输出，但从进制转换开始都很生硬。为考而考。

第二个例子就更加为考而考了，硬件和软件考虑的领域完全不一样。假设你想考高级语言语法树到机器码到 CPU 硬件加法器的全实现，那其实只问「写下这行代码到输出结果发生了什么」也是可以的，为什么要先问怎么实现加法器呢？

加法器可以由不同的逻辑门构成，但你知道为什么要选用特定的逻辑门来做吗——是集成电路印刷工艺的限制，材料、印刷难度、功耗、成本等。如果我需要考虑集成电路用什么逻辑门，要么我考虑的是前面讲的这些东西——这与你要考察的核心内容相去甚远；要么我在做一道没什么实际意义的智力题。

面试不是知识展示，而是能力考察。你知道他知道更多东西的目的是确认他能做更多的东西，你并不需要确认你需要做的东西以外的所需知识。

举个实际点（但其实也不是很有意义）的例子： /t/860741
我可以通过「为什么会输出乱码」考察 unicode 的码表、编码、平台相关实现、语言相关实现、unicode 库的使用经验、内存安全性、web 安全（ utf7 ）等等知识，它们都可以从乱码这个话题展开，而且编码转换、操作系统适配、内存安全、web 安全都是比较实际的话题。


----

题外话，学生时代都有种「做题优越」，因为学生时代的竞争力完全体现在解题上，而不论题目本身是否有价值。
以后你会发现竞争力来自于「给事物赋予价值」，是很不一样的。

告诉几件 OP 无法理解的事：

1. 只有你自己才知道你有两台设备，其它人不知道。
2. 只有你自己才知道你把验证器装在了哪台设备上，其它人不知道。
3. 只有你自己才知道登录验证的 require 弹窗和 confirm 弹窗弹在了哪台设备上，其它人不知道。


> 就因为安卓备用机登录了账户，死活必须让验证 → 这是正常逻辑
> 那你还弹出 TOTP 让我验证干叼 → ？
> 都关机半月了 → ？
> 本机也没暂停过使用服务 → 本机？是说这个备用机不是「本机？」那什么东西关机半个月，和暂停有关系吗？怎么就智障了？
> 如果 TOTP 不能作为验证手段，那就关了吧。→怎么就不能了？
> 而且开机的 IOS 就这么视而不见？？→ ？？？ 哦意思是「本机」是 IOS 是吧，那非本机登录要求验证哪智障了？

----

抛开逻辑破碎不谈，难道不是 A 设备登录->B 设备打开验证器->A 设备输入 B 设备获得的验证码就好了吗？

我只能猜测是你 B 设备打开验证器这步遇到了问题，但你从头到尾的追加都没提到相关信息
那我只能认为也不是这一步
但登录和输入都不可能有问题

于是我推断 OP 想等 confirm 弹窗但是 B 设备就是不弹，他就是不肯用输入验证码这个方式或者没有这个方式，结合最后一个追加的图上有显示「使用验证器获取验证码」，那排除没有这个方式；


结论只能是

OP 想等一个 confirm 弹窗，但 B 设备也就是他的主力机 ios 设备，没有弹，于是他认为 google 账户验证很智障。

@James369

你的理解有误，tag 就是指向具体 commit 的标签，跟在哪个分支无关

master 分支的目的是公共 checkpoint ，包含每一个完整的 feature ，与之对应的是 dev ，会包含尚未完善的 feature 。master 上每一个 checkpoint 或者 merge 点代表完成一个完整 feature 。

release 分支会有很多个（ release_v1, release_v2 ...），它们与 master 永久分岔，目的是存放所有已发布的历史线，如果不需要对外提供旧版本的 release ，那么旧的 release 分支其实可以删掉。之所以分岔的原因是，master 会有新 feature 和新 fix ，但 release 上只会有新 fix ，历史与主线是不同的。release 上的 fix 一般通过 cherry-pick 获得

如果完全不需要对已发布的版本做修复，而采用修复随版本滚动提供的方式，那么完全不需要 release 分支，只需要 tag/release 就好。 tag 的作用是给 commit 做特殊标记，由于有意义的 commit 一般在 master 上，所以 tag 「碰巧」打在了 master 上

@unt
杜绝相互合并，尤其是双向三路合并（ git merge ），即 a merge b, b merge a ，which is extremely evil ；
严格遵循单一公共线原则，即使是 feature 分支，也要有公共的 feature 分支+feature_a_dev+feature_b_dev ；
推送代码前必须先拉代码;
严禁任何分支 mege master ，只允许 master merge dev

推荐在 feature 和 dev 分支上禁用 merge ，只允许 rebase 。但 rebase 会导致目标分支历史重写，所以有第二条，尽量只重写自己的分支，避免公共分支被重写干扰其他人

我有个印象，可能记错别太当真，就是，golang 会把函数内所有变量和参数都复制到栈上，所以可能只要 sp 指回来整个栈帧就能恢复

@Doracis rebase 到 3 个 commit 前出来 19 条没遇到过，但猜想是你 rebase 的目标经过了一个 merge commit ，导致历史混乱。应该先把 merge 后的 commit 暂存（ cherry-pick 到临时分支或者 stash 起来），reset 掉 merge commit ，然后再重新 merge ，再 pick 回暂存的东西

提示 allow empty 常见场景是你从 A 分支分岔开发 B 的时候发现有个 A 的 bug 要修，然后你在 B 上提交了一个 a(1)，并且把这个 bug 告诉了其他人，它们也在 A 上提交了一个 a(2)，当你要 rebaseA 把 B 的历史接到 A 后面时 a(1) 就是个空修改，因此可以直接舍弃掉。还有一种常见是 a(1)和 a(2)发生了冲突，你解决完冲突临时 commit 的修改与 a(2)相同，临时 commit 就变成了空的，也可以跳过