有点难但不算过分。

当然了，你说面试官态度不好这是另一个问题。如果他不是之前被其他人恶心过或者今天心情不好的话，那这个面试官表现就非常不对劲了。

另外，与其先 revert 再 merge，你可以切到 release 分支，reset hard 到 mainline，然后 reset soft 到 release，然后原地提交，就能做到他提到的「 we copy mainline into this release branch 」了。

他表明了一种可能性，而不是一种必然性。
你这里的 F1 和 F2，与上面两个黄色的 F1'和 F2'已经是不同的提交了。
当包含相似但不同提交的分支最终合并到一起的时候，什么事情都可能发生。

这就是为什么：
1. 我们一般不会用 long lived release branch
2. 我们一般不在 merge in 的时候顺便解决冲突

你这样做对团队的要求更高，因为潜在造成 merge conflict，所以你的很多 merge commit 都是内部自带修改的。换句话说，你的补丁不再是 F1，而是 F1 加上 merge commit 两次修改。如果以后有人要 revert 你的修改，他把 F1 给 revert 了，很有可能就有漏掉的 merge commit 改动没有被包括进去。所以我个人的习惯是 merge 必须是 clean merge 。

再说这个 long lived release branch，实现的效果就是每次到 merge 点的时候两条分支内容相等。
那既然分支已经相等了，那么 release branch 的历史其实已经没有用了。
那么还不如直接从发布 commit 直接重新分叉一个 branch 出来来得简单。

换句话说，你图上 F2 和 M4-7 中间这条线，是可以直接删掉的。
删掉以后就是我们常用的 release branch 方案了。

我来说个小众的。

sss='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

专门用来连接一些第三方的服务器或者临时开的虚拟机，既不需要确认，也不会污染 known hosts 。

@zhaorunze 说推导出代码很烂的不是你么？ @abcbuzhiming 可没说微软代码烂。
你是不是眼神不太好。

你是说 rust 还是说 C++23 ？但是最后你不是还得回来写 plain old C++吗。

@lululau #9 正解。《不要》和《不要》的意思不一样。一个是劝阻，一个是表达意愿。

@leafre binary 在缩写成 bin 的时候就是读成病的。
周围不管哪国人，包括美国人印度人等等，遇到要读 /bin 之类时候，都是读成病的，没见过读成掰的。

顺便一提，很多缩写的读音会照着缩写后的发音习惯来读，而不是原始读音。
比如 ICAO 国际民航组织，其中的 C 是 Civil 的缩写，但是缩写后这个 C 取 K 的音，ICAO 读作爱 K 欧。

@bleaker 这太草了。

还有一种做法就是允许其他人抢占锁。可以无脑参考一下 WordPress 之类软件的设计。

写惯了 Ruby 的人写 Coffee 是真的舒服，我现在都特别想用 Coffee，只是公司项目肯定要考虑别人的感受，不能用。

只是 crud 的话 rails 还可以吧，再多了就不清楚了。

> 是不是克隆修改 LICENCE 的 commit 前的 repo 需要遵守 GPL，而克隆之后的代码就要遵循 Apache 呢？

是。LICENSE 对应 LICENSE 所在的版本和项目。你需要遵守你所使用的这个版本的许可证。

至于楼主的想法，我建议你自己去开个外卖店。
享受一下被平台强制摊派折扣的感觉。
比如一个餐定价 20，人家用个红包减 10 块，这 10 块是你自己掏腰包。
等你掏到破产以后，可以来更新一下帖子，告诉大家外卖的价格到底应该定多少。

@dyxLike 人家店家已经把价格标上去了，这不就行了吗。
什么时候轮到坛友教商家做事了，人家关不关网店管我们屁事……

我们这外卖也都是这样，平台点餐每个餐都更贵一点，然后还要再加服务费派送费税费小费。
不喜欢外卖的可以上门取餐。

从定义上就不满足了。没有判断的不能叫编程语言。

人脑挖矿 PoW 。

带个泡面盖看书如何？

常见两种做法。
1. 依赖 stash，先存进 stash，然后切换分支，然后放出来。
2. 依赖 commit，先提交成 commit，然后 rebase 分支。