先说什么发行版什么版本。

@codingKingKong
AB merge 方向这个我也不是很清楚，但是如果本身没冲突的话 3-way merge 完的结果应该是一样的。有冲突的情况下，可能先合并的更改会改变后续更改的参考系，所以可能会产生结果不一致。

至于项目管理的话，我们一般是一个 feature 一个分支。一旦某个 feature 定稿合并以后，其他 feature 分支需要 rebase 到 tip 上然后才能 merge。

所以我们的分支图大致是这样的：

https://i.imgur.com/dG0EM7G.png https://i.imgur.com/XyH44ny.png

以及之前的反面教材：

https://i.imgur.com/U54T03C.png

（不知道你能不能看到图。）

另外 force-push 一般是不会丢 commit 的，只要之前那个正常 push 的人重建分支就行了，很简单的。
用 Git 这种多人协作工具，一定要保证每个人都会用 Git，然后才能放进来做贡献。之前我进公司以后看到公司里十来个完全不懂 Git 怎么用的人，真的是心态爆炸。

@k19870203 是 3-way merge，但是 apply diff 的顺序是不一样的吧。先 apply A-O 再 apply B-O，还是反过来，可能就会影响冲突判定了。

至于解决冲突，因为解决冲突本身是包含在 Merge commit 里，实际上一般不会有人特意去写这次 Merge conflict 到底改了哪些部分，甚至都不会说这个 Merge 做过了额外的修改，所以追溯的时候就会出现一个没有修改说明的修改。可能合并前测通了，合并后崩了，然后你发现是 Merge 的时候有人改错代码了。

买充值卡冲进账号里比较靠谱。
如果是别人开号给你，或者是教育版，当然都是不靠谱的，能用的时候用，没了就没了。

浪涌插座，开关排插，做法多得是，何必拔线呢，你就不怕把插头拔坏了……

Merge 的时候，A 向 B merge 是把分叉点到 A 的更改做成补丁打到 B 上。
B 向 A merge 是反过来，把 B 的更改做成补丁打到 A 上，具体的算法实现是不一样的。

另外我们的习惯是做 rebase 后再 merge 回去。
非 clean 的 merge 会导致 conflict resolving 产生的更改被隐藏在 merge commit 里，无法追溯。
我们实际遇到过这问题，feature commits 和 merge 后的 tree 内容不同，后来发现是 merge commit 里有人做了额外的修改。

Git 你要是闭着眼睛颠来倒去尝试，看哪个能跑通就用哪个跑，那这个 repo 没过多久就得乱成炸酱面了。

所以主函数在哪……

→_→为啥你觉得点了取消以后钱会回来呢。

首先要开工单询问啊。

和 Hetzner 比有多少优势呢。

test ALL=(ALL) ALL
test ALL=(ALL) NOPASSWD:/bin/ls


test@debian-ws:/root/test$ sudo ls
01
test@debian-ws:/root/test$ sudo vim
[sudo] password for test:
test@debian-ws:/root/test$

看到你的帖子我就猜到大部分人猜不出你想问什么。

现在 Intel 就是跑着 AMD 搞出来的 64 位指令集→_→
然后还做得漏洞一堆，最近这一年不停地再打补丁……

我现在帮客户推荐虚拟化服务器平台都在犹豫要不要上至强了，太坑了最近那个超线程漏洞。

@bugeye 辛苦你拍脑袋脑补了 2 行半。我就不反驳了，你开心就好。

@yinanc 而且还要加上，那些翻译过的人也是学了外语然后才能翻译的。

整个点子里，「怎么实现我不管」这部分价值千万美元，剩下的部分价值 10 块钱。
你还不如灵机一动去小行星上挖黄金了，怎么把人类送上天我不管，只要送上去挖黄金回来卖就行了。

@passerbytiny 模拟多客户端连接不就是多线程吗……除了改了 user-agent 以外？

并没有破解吧。免费用户下载大量文件以后就会触发 10KB/s 左右的限速。
如果是付费用户，IDM 和 aria2 就只是多线程下载。

@pony279 Ubuntu 是基于 Debian sid，也就是 unstable 分支，不是 testing 哦。

@likuku docker 还是比虚拟机轻些。我自己就是把 docker 当 vagrant 用，Dockerfile 写好构造命令以后拿来编译软件包。Debian 本身自己就有这个计划，把软件包放进 docker 编译，可以保证编译过程能到处 reproduce，我是参考了他们的做法。

CentOS 是一个企业级操作系统。如果你打算以后加入大公司，成为运维团队的一员，协助维护几十几百台服务器的，以及后期可能会转去 RHEL 的，这样的选择很好。
自己个人使用为什么要用 CentOS 呢，你每个月会花多少个小时来打理你的系统呢，会自己写脚本然后管理自己编译打包的软件包吗，会跟着 RHEL 的安全更新公告然后半夜 3 点起来扒 0day 更新吗？如果不会，那么为什么不去用 Debian 呢。

你自己运营一个云服务，同样的机器配置同样的月付售价，你能做到不超售资源然后盈利我跟你姓好吗。