@LeeReamond

#include <stdio.h>

int main() {
int data = 0;
void func() {
data = 3;
}
printf("%d\n", data);
func();
printf("%d\n", data);
}

# ./test
0
3

上面#10 说的其实很好。
面向对象设计是给数据绑上了方法。
面向闭包设计是给方法绑上了数据。

@himself65 是啊，GNU C 里的。
不过，如果是 GNU C 里的 nested functions 的话，GNU C 是支持 nested functions 访问外层局部变量的。

我是搞了个 cloudflare worker 来连 Google Drive 和 OneDrive 。

Lisp 。

话说首先你 C 语言的例子就错了，data 不是全局变量，C 语言里也没有 nested function 。
你例子里 func 是和 main 平级的，func 当然不能访问 main()里的局部变量了。

@bclerdx 离线硬盘，刻录光盘，加密网盘存储等。

GTX950 这个级别就可以。1030 应该也可以解。预算足可以上 1650s 能打打游戏还能解码 8k 。

@sillydaddy 方向反了。
应该是让分支 rebase 到主干，你说的那是把主干 pick 到分支。所以我才说不管是 pick （或者你说的那种反向 rebase ）还是 merge 都是不合适的。

rebase 不是基于 cherry pick 。这两个命令本来就都是 commit 的语法糖，没有内部不内部之分。

@sillydaddy
我又特地看了一下，微软的这篇文章其实也不对，最合理的做法是 rebase 而不是 cherry-pick 或者 merge 。

@yogogo @sugarkeek
这两个东西原本也不是冲突对立的。
版本需要开分支，是因为会有稳定版和开发版之分。
功能和模块开分支，是因为要多人同时进行开发。
比如你们 1.5 版本发布后，开始开发 1.6 。那么可以先分出 dev-1.6 分支，然后在 1.6 分支上再按照 feature 分出不同的分支。开发完以后先 MR 到 dev-1.6 上，然后等全部测试完了，再 merge 到 master 上，发布上线。

@sillydaddy cherry-picking 和 merging 本质上是差不多的，这和无声无息也没关系，不管有声还是无声，最终都只有测试才能决定合并是否安全。cherry-picking 无错并不代表合并成功。同时这也不应该成为不用 cherry-pick 的理由。

写了一大段，想了想，全删了。我在这着什么急呢……哎。

还是那句话，你自己都不屑用的项目你指望别人用。

当然靠集成测试了。两个分支合并产生冲突的话，不管是取其中一个分支的代码，还是把两个分支的修改合并在一起，都有可能导致代码出问题。

简单说就是后合并的分支需要重做。

强烈推荐多看看 LPL 的视频。
到他手里能撑过 2 分钟的锁那已经是世界顶尖水平的锁了。
普通的号称撬不开的锁他几十秒就能开。

https://www.youtube.com/watch?v=NSuaUok-wTY

重要文件用酷狼，下载盘用企业级，ermmm……
我宁愿重要文件用企业级，比如 Exos 或者 HC 。

迅雷会自动分享你服务器上的文件地址给其他下载者，所以不要在服务器上放本来就是公开的文件。
这个我们十几年前就吃过亏了，服务器上有个内部用的视频，结果一个组员脑袋一抽用迅雷下了。一觉醒来服务器被拉了几百 G 流量。