正常都是开发者自己解决冲突，不限制解决冲突使用的工具，测过了再提交，而不是滥用 Web 编辑器让公共分支变成不可维护的临时 patch 火葬场。
Reviewer 只需要对 diff 和 merge 结果负责，不需要对具体操作负责。
即便要用统一的 flow ，Gerrit 之类也有事后诸葛亮。
实际上 merge 不见得应该是首选项。要 merge 还是 ff-only 还是 squash ，你作为分支的 owner 应该清楚。或者你就不管，活干完了找清楚怎么处理这些问题的专人负责。

@3dwelcome 非要死活抱着不放 VS ，那也是直接升级省事。老项目迟早得寄，趁早重写。
正常的 C++“老项目”很少会有升级语言特性导致源码层次上出问题挂的。
C++17 以来的一些自作聪明的如 char8_t 和 lambda 默认 capture 的更改让源码兼容的问题变得极其蛋疼，但那是少数。VS 这几年默认都用的 C++14 。
升级 VS2015 都会出问题，要么是在依赖旧版本 VS 专属的 bug ，要么就是代码本来就有 bug 没让 VS 发现。横竖都是代码实现质量有坑。

@BrettD 不建议玩这种魔法。VC++2015 以来的二进制兼容保证有一个理由也算是为了你少倒腾这种非主流方案。
我就有一次被逼得同时 VS2008+VS2010 一起开的经验，是因为某个欠扁的静态库依赖 VS2008 的 libcmt 。这也就是严格分离依赖的情况下才敢搞。

@LotusChuan 习惯是习惯，但是习惯得只剩下习惯，逻辑上有时候就有点欠扁了。

（先明确大括号说的是复合语句的边界；其它情况，像 int a[] = {42};之类的情形，就算鼓吹换行的正常应该不会强迫症到强行换行。）

大括号换行的习惯大概是因为一些 IDE 的默认格式，根本是{和}的水平位置竖直方向上对齐，容易辨认。如果不换行，找起来就困难一些。
不对齐的主要理由是省空间，单独一行大括号毕竟太占地方。这个说法像++--和中缀声明符等经典 C 反人类设计一样看似有理，但仔细一想就明显双标：真想省空间，应该顺便}}}}了。

说这是 K&R 的理由应该比较充分。
注意 K&R 的风格{}换行也并不一致：函数体第一个{是换行的。因为 K&R C 函数定义中，参数的类型声明是在)和{之间，经常还需要一长串单独列出，和函数体的外层{}有必要区分，这还算能理解。
然而就是 K&R C 的函数语法，显然也不如全换行一致容易理解。奈何原作者就这样，相当多的用户入门起来也懒得多想，就有样学样咯。
更过分的是 C++和 Java 之类根本没这种语法的语言还照搬，就明显犯二了。
所以说是经典，还不如说就是教条。
K&R 的这种过气货还隔空殃及其它设计。C 函数的函数体必须是{}为边界的复合语句，这个在语义设计上是很没道理的——撑死语句就够了，不用{}这种废话。也就是因为 K&R C 的函数定义才有必要如此：如果没{，)和后面的语句之间的边界很不好分析。
结果这种设计被照抄到 C++的函数、Java/C#的方法等等一大票语言的语法中。C++“兼容”C 函数定义也就罢了，然而 C++11 的 lambda 都省不掉{}（ Java 和 C#的倒是没有），这就是另一个境界的二了。

（ emm ，C2x 终于要移除 K&R C 函数定义语法了，可喜可贺？）

@xiaotianhu 看到这里就得提一点：滥用“补全”是偷懒职业病，得治。

专业开发人员的正常工作流程就是应该熟悉实现设计需要使用哪些 API ，需要从哪里取得文档和支持。
开发工具提示 API 和文档是辅助，而不是替代。找对和正确理解文档是本分，“记忆成本”从来就是开发经验的一部分。
什么时候成了不清楚自己要调用什么东西随便输入个什么东西去补全指望蒙对了？正常不应该是理解实现方案需要花时间考虑清楚，真输入代码了顺手根本不用停，然后偶尔发现补全对了所以顺便少按键盘？

真要日常补全会显著加速的情形，无非是 API 里的标识符普遍又臭又长（比如某果家的）或者语言本身导致语法上的 boilerplate 多得要死（比如 Java ），结果换个普通点的文本编辑器就寄了。
C++是有不少废话多的地方，但不是在这个层次上，编辑器自然帮不上忙。（如果发现少补全才是槽点，大概是没能力发现最欠揍的一些地方的。）
但剩下麻烦的地方是所有用户都得被坑的。所以不挑编辑器和手速，强调用户对语用的理解，让有能力的开发者随意加速气死剩下无能狂怒的，这对专业开发者明明是优点好不……

@3dwelcome std 的东西你要发呆到什么时候？
大部分 sln 根本就没鸟 MSBuild 的特性，再加上 MS 的人自己就在嫌弃（ STL 迁移到 cmake ），所以实际项目很少会需要你折腾的。
大多数情况下，配好工具链直接一个 g++ *.cpp -Ixxxx 都能应付了。生成库无非需要多加点选项。
啥，你非要纠结 cl ？那只能说你活该非得盯着 VS2015 的过气货。

退一步讲，不就是个 string_view 么，自己手糊个什么难度？……抄总会吧？
github.com/FrankHB/YSLib/blob/master/YBase/include/ystdex/string_view.hpp
（只保证 C++11 能用，不对 cl 的 bug 负责。）
又不是叫你实现 is_constant_evaluated 。
说实话而且这玩意儿常见得发指，boost 里有 abseil 里有甚至 GitHub 一搜一大把，还都是 header-only 的。
你就是在找发呆的借口吧。

@Mithril 关键问题是，“法务”不一定存在。不存在法务正是有必要了解这里的问题的主要原因。

许可证首先为可能有权决策使用许可证的用户服务，最主要的就是版权持有者。
最常见的情况是版权持有者就是作者，能完全清楚自己决定什么权利。
这里还没有“法务”，于是作者自己就得全权负责。这种用户一般也不会得到外部的法律援助，因此是最需要清楚这里的问题的。
而首要问题是作为作者行使的权利。很少作者会同时具有申请专利的标的，也不会成为专利诉讼的目标，所以这不会是首要的问题。
虽然这些作者迟早需要理解专利问题，但这里有个先来后到。

法务是较大的版权持有者的代表，和其他大多数用户都不属于 OP 标题的“程序员”，因此我没有在这个角度上展开问题。
对受雇完成职业作品的程序员，首先应该了解雇主的政策。就行业惯例来讲，遵守专业法律人员参与制订的规则就已经足够。专利风险的审查由专人自上而下负责，基本不会由程序员兼职。除非有明确约定，汇报专利风险对程序员来讲不是职责更不是义务。

剩下的一种情况才是下游开发者中的项目负责人，也就是你所谓的用户。这种用户身兼程序员和法务的职责，同时需要负担开发和决策任务，特别是对他人被动作出法律担保，所以非作者权显得更加重要。
但是，这样的用户一般都是从独立的作者升级上来的，自己会有清楚的理解，所以不太会有这里的问题。

@misdake 还是有距离的。
Markdown 一开始发明出来就是预期被翻译成 HTML 的，所以排版和样式功能的空缺可以用和 inline HTML 和对付 HTML 的技术（典型地，CSS ）补足。
而 CSV 就不是用来实现计算的语言，里面能拿来作为 inline 候选的东西都不存在……更不用说替代 Excel 也有的样式和内嵌其它对象的“高级”功能了。

typo：把版权捆绑在开源许可证上是个次要的实现问题→把专利权捆绑在开源许可证上是个次要的实现问题。

@Mithril 在外行直接拿来用的情况下，版权法和专利法的默认条款会同等地自动生效而发生侵权风险。对这些法律的用户来讲，最优先了解的应该是这种机制，然后才能评估风险，保护自己和相关涉众的合法权益。

在 FOSS 的实践中，一般意义的许可是重要的，但是否涵盖在开源许可证中而不是单独的其它法律文件，是另一回事。即便不算侵权风险的相对多少，专利许可的必要性也不可能和版权许可相提并论。因为：
1.专利法的特性决定了它的适用情形严格比版权更加受限。例如，版权的授予基本是自动的，而不需要申请，而专利需要到专门机构申请公示。
2.专利在大多数人有生之年可以过期还可能被宣告无效，指望版权不起作用现在基本就得医学进步了。所以遗漏专利许可在时效上的负面影响比较短。
3.关于软件的专利先天有一些法理争议，保护的法益也不够明确。这导致专利的国际认可程度较版权低。有的管辖区（如新西兰）压根就不承认软件专利，法律适用时是不是有授权一个样。
4.专利授权的条款技术上比版权远远更麻烦。FOSS 中大量的缺乏专利授权的许可证大行其道甚至越来越流行，比如所谓的 MIT （不管是 X11 还是 expat flavor ），在微软等大型实体中都是首选，这是个重要原因。

这些问题不表示了解专利不重要，但也说明专利授权的实践被相当多数涉众认为不值得和以授予版权相关为主要目的的许可证的捆绑。
有趣的是，除了许可证条款技术复杂开销，一部分用户除了看来是为了排斥软件专利而故意忽略了专利许可，显示出一副爱用用不用润，专利问题与我无关的态度；至少在没有 DMCA 这样允许强制下架的法令下，这实际上仍然相当有效。这和 FSF 为了规避法律风险在 GPL 里的繁文缛节这样完全相反的实践出发点却可以说是相同的：否认软件专利的普遍合理性。

当然，也有相反的做法，比如 LLVM 切换许可证正是为了 Apache 的专利条款。不过并非所有人认为值得这样做，所以是否合适在普遍上仍然是个有争议的话题：
https://news.ycombinator.com/item?id=12617881

另一方面，仍有其它专有权利习惯上总是不被开源许可证捆绑，不论是否在美国。例如，许多 Linux 发行版的厂商（如红帽）通过单独的 EULA 等其它形式明确用户不得未授权使用商标。
这进一步说明，把版权捆绑在开源许可证上是个次要的实现问题。

当然，你可以说，OP 在《常见许可证及其差异》这里表述确实不充分，因为专利条款一些许可证之间的确实是一个比较显著的普遍差异。
但是，即便是评估 OP 的重要遗漏，技术（法律意义上）上仍然还有更优先的问题，这至少包括许可证兼容性和再许可(relicensing)。实践中这里的问题甚至经常比专利侵权的成本还大（毕竟大部分 FOSS 项目还不会有价值被盯上而不得不去应诉）。这些恰好又是开发者相对法务更容易解决的问题。
所以，以上种种问题说明，即便排除版权和专利侵权风险问题的差异，单就许可证来说，专利也难以称为“最重要的”事项。而特定于 FOSS 的个人贡献者，签署 CLA 之类的许可证以外的文件的意义往往是更加需要了解而时常被忽视的；不过这就似乎更加离题了。

@darklights 只有 C++11 能用，不用 bind 怎么模拟 capture-init ？自己写？
也不是没理由自己造，比如 wg21.link/p0826 。但是这种问题遇到的概率比你 function 的坑小得多，类似的逻辑就更没理由去用 std::function 。
作为通用目的的 call wrapper ，std::function 的 CopyConstructible 要求本来就是个二缺设计，跟核心语言的 copy initialization 要求格格不入。最欠的是这种要求直接写在了 ctor template 里，所以用户能保证自己不 copy 也会被坑。
反正我是选择自己糊：
github.com/FrankHB/YSLib/blob/master/YBase/include/ystdex/function.hpp
正好干掉不支持分配器、不支持定制空调用行为和某些实现依赖 RTTI 的代码膨胀之类乱七八糟的屑问题。

@dorentus 系统显示的内存占用变小，可能是被压缩或者交换。前者的效果不确定（除非进程真是傻乎乎分配极大量连操作系统都认识的站着茅坑不拉屎的页——这也就是被烂应用逼的），后者以系统响应（以及其它次要的，比如硬盘寿命）为代价。两者都是全局有限的，所以流氓进程一多可能绷不住。这些机制主要是为了优化吞吐，把系统潜能抠出来，所以对响应天然不友好。而对合理利用存储的进程，两者效果都有限。
你看看活动监视器内存选项卡下方的变化，至少交换多用了多少应该看得出来。或者用 top 看实时的 RSS/SwSS 。

@dokimaster ARM 里对应 x86 的 BP 的叫 FP(frame pointer, r11)。

@Cloutain 真实世界的寄存器种类就多了去了，不说物理结构，光是 CPU core 内架构以下你就得区分物理寄存器文件（ PRF ，或者叫寄存器堆）、非架构寄存器（包括 MSR 、隐含的寄存器栈以及架构不可见的其它内部实现）、（可能重命名的）架构寄存器（里面还有通用 /非通用寄存器）、ISA-level ABI 约定的名义寄存器（比如这里的 sp ）等等一大坨玩意儿，以及落实在 HDL 代码（主要是 RTL ）上的那坨……然后其它设备内或者和 CPU core 通信的还有用到寄存器（比如 I/O 寄存器）……ISA 以上，高级语言翻译的低级 IR 也有叫 RTL 的，也有其它 IR 多糊出来的虚拟寄存器，还有 VM 的架构寄存器、高级语言过程约定的名义寄存器等等。
所以遇到这种笼统问题，先反问面试官想知道个啥？

如果专指物理实现，CPU 里的笼统就是时钟信号控制的数字逻辑电路，具体也有不同方式。PRF 的常用的是 SRAM （别的像触发器面积比较吃亏），至于 SRAM 怎么实现也不止一种……懒得套娃了。

@dokimaster ARM 的官方 ABI 有明确约定 SP （ r13 的别名），并且逻辑意义上硬件做得比 x86 还多（架构上有更多限制），汇编器都直接认识 sp ，所以你这个是不懂强答露马脚了。
这类问题跟面向对象的坑和误导流毒到处都是不一样，应该很容易就能找到权威参考。事后你没确认过自己是不是记错了？

“x86 和 arm64 为什么有区别”？
没问你具体啥区别么。那答案简单——“废话，又不是直接抄的，还是说你认为 ISA 设计随便瞎蒙就英雄所见略同了？”

面向对象这个你是跑偏了，原版（ Alan Kay ）吹的那个行为是通过消息交互体现的，对象的数据和行为构成接口，这时候还没类什么事。
而所谓的方法原本是具名的消息关联的原语，但现在更多的是特指基于类的面向对象风格里从 Simula 挪移过来的杂交概念，即从属于类的、跟随类的接口设计确定签名的一种过程(procedure) 。
（虽然我也不信一般没对考古特别有兴趣的面试官拎得清楚这些。）

@Mithril OP 一开始就没说这个话题有意只关心具体许可证的作用。（看上去是无意遗漏的，所以我指出了这个问题。）
就常识来讲“程序员们都应该知道的各类开源许可证”的“知道”的前提首先是清楚“开源”，而不是“许可证”，后者是实现前者的手段。
如果要点如何实现事务性地合法，不需要加“开源”修饰。这样，分析具体开源许可证就不是重点了。即便如此，关注专利仍然不会比版权问题更重要，因为外行最常出现的只管拿来用的情况下，后者的问题几乎百分之百存在，而前者很大程度没有争议。
这些常识合格的法务也都清楚；如果你不确定，可以咨询你司法务。
所以，关于专利这样的其它问题，和 OP 说的内容没有直接关系。

即便有的开源许可证一并捆绑附带专利许可，这也只是一种补充。但须知，这也就是可选项，还不是业界一致同意的做法。
使用许可证捆绑权利声明的做法流行于美国。而在欧陆传统中，版权和其它专有权利向来就是分离授权的，所以有的作者甚至明确反对“许可证”这个形式本身，以避免暗示的适用法律错误： https://marc.info/?l=openbsd-misc&m=120618313520730&w=2 。
法务可没有理由因为自己只习惯美式风格，反对这种分离许可的实践而不干活。

@dorentus “小小”的用户空间程序，首先说的是存储所有权和默认优先占用运行时资源的地位。不论相对内核还是用户，它就应该保持卑微。做了显然违反用户需求的事，而用户没有误操作，那就该出来挨骂。
因为没有资格僭越用户的需求，任何用户空间程序在没有明确得到授权或请求时，在多任务系统上就应该保持保守占用资源。这是本分。

你的截图中的 2G 多的占用相对 OP 的例子看似不过分，但考虑 xcode 干的事，已经开始离谱了。
xcode 调用的真正干活的必要开发工具（编译器和链接器之类），乃至一些分析工具，都是单独开进程占用资源的，而要编译链接占 2G 多的规模程序的项目已经不算小了。对这种体积的项目来说，相比之下，devenv 分析完同时开几十个文件稳定占用也不过几百 M （这还包括没通过 clangd 之类另外的进程外包出去的活）；所以即便只是个开始，也至少说明 xcode 很拉胯。
并且，这不支持你的观点。你说“不用拿来做什么”，言下就是在你这 xcode 用得还不够多。OP 遇到的状况反而还比你完善一点；但是，体验毫无疑问地糟糕。

所谓“内存万一不够用怎么办”这就不可能只是操作系统需要考虑的事情，因为操作系统没有道德义务也没有技术能力对犯傻没下限的应用负责。可见的未来，操作系统不可能智能到真正区分出一个应用到底是确实需要分配资源还是有很大嫌疑占着茅坑不拉屎，因为这涉及对任务内容的主观价值判断，而瞎判断 OOM 乱杀任务的问题上面已经说了；所以哪个任务占用过多哪个任务欠杀，必须依赖用户的决断。
（若有不服，你可以先搞出一个带有强人工智能保证不会比现在的人类用户误判更多的操作系统实现来试着让和你观点不同的用户闭嘴。）
操作系统能做的也就是提供简便的接口放权给用户（顺便，这也是 Android 和 iOS 做的比几乎所有桌面系统更烂的地方），反过来用户同样有义务了解这个局限性，清楚不被信任的任务可能被干掉。
一般意义上，操作系统的用户包含应用和最终用户，无论是应用占用资源的策略还是最终用户选择是否启动并容忍任务对资源的占用，都是人（应用开发者或者最终用户）在根据任务自身的是否有理由继续存在的主观判断直接或者间接地作出决定，而不是机器的思考。不管是开发者还是最终用户，放弃行使这种权利理应后果自负；你所谓的“太闲”，不管出发点是什么（基于对机器能力的蜜汁自信，或者对人类用户的权利的蔑视），完全是颠倒黑白，可以说非蠢即坏，并不冤枉。

顺便，历史上，乔布斯是一贯蔑视消费产品的最终用户对和自己不同的产品方面理解的能力的，最好用户都是傻子。但 xcode 作为一个用户不能太傻的开发工具，苹果还没好意思把逻辑一起贯彻上。
你是想进一步教苹果做产品么？那么第一步，你看来就不该承认内存泄露的 bug ，而是说，这是 xcode 的伟光正开发者决定的 feature 的一部分，至于具体是什么你们最终用户不配管，爱用用不用润。

@Mithril “限制商业使用”的内涵不只是你说的这些。限制下游销售作为软件组件集成的软件明确违反 OSD 第一条，直接就不是开源许可证。
相比之下，所谓专利授权，完全没同等排面。不授权专利的 permissive 许可证多得是，并不违反 OSD ，何来“最重要的一部分”？
顺便，也就是因为 SSPL 对 AGPL 修改的条款的模糊性，而不被认为是“开源”的：opensource.org/node/1099 ；这种修改涉及用途上的歧视，而被普遍抵制：www.infoq.cn/article/j8hogct5x_exxvf6cxve 。
到底是哪个垃圾碰瓷哪个就另说了。

你漏了最原则性上的文献：怎么界定算开源。
opensource.org/osd-annotated
许可证可以自己写，你列不完。

@dorentus @deplivesb 这种调调是病，得治。
用不用是系统根据用户意愿决定的事，多任务系统下什么时候轮得到你一个小小的用户空间应用来显摆了？
你个应用说，我要完成的任务占用存储天生下限就高，不给够我就罢工，那行。但你个 xcode 是什么牛鬼蛇神，完成的那么点任务，也配上来随随便便就吃个几 G ？真当自己是在整 Chromium 的 ld+lto1 了？
退一步讲，你要是给服务端应用做极端吞吐量上的优化，开起来以后就不打算动，那也就罢了；偏偏这就是时刻要求维护系统响应的典型客户端环境。
“内存不用拿来做什么”，哦，你 xcode 是用户脑子里的寄生虫，知道用户不用立即多运行其它占用巨大运存的程序？万一不够用开不起来了或者被迫 swap 卡翔了，浪费的操作和时间你 xcode 赔，还是说用户活该用你 xcode ？

同理适用大多数 JVM 上的客户端应用，以及 Linux 有大病的默认 OOM killer 配置。（所以 xcode 就更拉胯了；明明苹果都知道 GC 和超卖 OOM 的下场，所以还刻意强调了 ARC 如何优越，作为门面的开发工具却还这般耍无赖。）
病不治的后果就是以后随便哪个系统上来多开个应用就卡翔成低端 Android ，可用空间真快完了又各种抽风；或者就是 iOS 的相机 app 一出，别的后台应用就该想着怎么“保活”了。
（虽然这不表示其它抽风的可能性不存在，例如 Win32 快 OOM 了 GDI 直接整不出来字，注销都没用。）