@mrcn 不是
因为 C++不像 Java 或者 JavaScript 一类的直接使用源码（字节码也算直接使用源码了）它用的是针对平台特化的二进制。所以没办法像其它语言一样直接拉同样一份库就能用。你得针对不同平台甚至不同 STL 编译出一份来。也没有像 Maven 或者 NPM 一样的东西，不然同一份代码你得编译几十上百份二进制存进去。
我了解到的，主流的都是在你公司内部部署一个包管理系统，因为特定某个产品支持的平台一般都是有限的，所以你可以只放有限的几份上去。
你说的这个并不是主流做法，版本控制系统设计来是针对纯文本的，它的 diff 并没办法很好的处理二进制。你也不应该把二进制提交到代码库里。
正常做法是，你开发了一个版本的代码，CI 编译成针对某个或者某几个平台的二进制并生成版本号，然后 CI 把这些二进制传送到二进制管理系统里。
使用这些东西的项目，会在编译期由 Build Automation 系统去二进制管理系统里面查询对应版本号（你可以把架构直接写到版本号或者 product id 里）的二进制，并下载回来解决依赖。
至于你说的代码版本和二进制版本的对应关系，CI 系统会有记录。而且很多时候你也会把这个代码版本记录到二进制的包里，或者直接打到文件属性上。
不要把二进制放到代码库里还有个原因，就是你只放二进制的话没有编译环境记录的。CI 系统会记录每次编译使用的环境变量，编译参数，而且还有 log 可以查。而且你会把 pdb 一类的东西也放到二进制管理系统里。你在代码库里提交一个二进制，甚至都不一定能和代码对应的上。到时候出了问题查起来就是灾难了。

C++的依赖管理有几种。
vcpkg，conan。或者包进 nuget 里。我们自己用的一个魔改过的 Gradle。
其实改个 Gradle 插件是最简单的，或者 Conan 也可以。直接用 Artifactory 存编译好的二进制。你在编译的时候需要的依赖都会拉取对应版本到本地，解压链接进去。如果本地有的话那就直接用缓存。
自己控制好版本和 Arch 依赖关系就可以了，改个现有的系统的话，这些基本都有办法解决。
其他的不推荐，特别是你这种做法。到时候部署版本出了问题，你都没办法追踪依赖版本。而且根据环境不一样，有的时候你编译的二进制也不一定一样。这时候你再去追踪调试就更没谱了。
依赖最好是固定好的，对于 C++来说，不要去直接依赖代码。除非你是 boost 那样直接复制进去就能用的，不然全部都依赖二进制。然后这些二进制如果是开源的最好你要么直接依赖官方发布的二进制，要么全部自己编译。而且记录好编译环境参数等信息。有些项目在编译的时候会读入环境变量，这种你更没法控制发布版本了。
所有你依赖的库，全部都依赖其二进制。然后编译过程中通过依赖管理系统去下载这些二进制，让依赖管理系统去解决版本号，Arch，冲突等等问题。不要自己手动去解决。
你现在这种做法不出问题就罢了，真的你哪个依赖库有问题导致发布版本出错，查都没得查。

一个佛都只渡 VIP 的地方，还有什么好说的。

@opengps 然而发现这么多年也没用到 int 上限？
其实你要做分布式的话，UUID 就比 int 好啊。如果只是单一数据库，那直接 int64 就完了。

@barble 我手里也没这种音箱。不过按理说这广播应该没什么用，除非是多机联动用的。就是你家比较大，几台音响互相之间可以广播不同屋子录下的内容。不然它这个功率泄露不了太远的，除非你用一个特别牛逼的天线去接。
但是要真是多机联动用这方案也是脑洞清奇，说明完全没把你隐私当回事。。。

早就不敢用百毒的东西了。。特别是 AI 音响这种。
不过这就过分了吧，把采集的环境音广播出去？这是人干的事？

不会，因为知道怎么远程办公的领导太少了。自己导致大家效率极端下降，完了再来一句咱们不适合远程办公。
这都什么年代了，需要 VPN 远程桌面回去写代码你敢信？就这样还怎么远程办公。

安全只能靠人的意识和策略，只靠技术是没用的。VPN 和 FRP 本质上没什么区别，你只要能访问到内网，那该炸就一样会炸。
作为公司而言，首先要确定对于自己来说什么东西是核心资产。绝大多数公司并非造火箭的，代码本身不值钱。是产品数据库重要，还是自身的销售渠道重要，还是真的代码最重要自己要想清楚。安全防护保的是核心资产，其他的价值没那么大。
比如你做互联网产品，那么生产环境是要彻底隔离开的。哪怕是在公司也不应该让开发人员可以直接访问到。这种情况开发人员在家办公还是在公司区别不大，只要做好代码库隔离，不要一次性把所有产品代码暴露给某个开发人员就可以了。

@kangsgo confluence 功能上没有可以与之相比的，而且教育折扣是半价。
两年前给公司选的时候试用过几乎所有的同类产品，功能上没一个能打的。
唯一的缺点就是性能一般，数据量大了以后需要堆硬件。贵不是缺点

@chenqh 如果你觉得以后会支持前端跑在不同时区，比如从国外访问，那你数据库就存 UTC。
查询的时候让前台给你传 UTC 时间。或者只存个 offset。
一般这些 ORM 都可以给你做了，配置一下就好了。
如果你这个产品从头到尾都不会有人在不同时区使用，那就直接本地时间也没问题。

大写字符是 65~90，小写是 97~112
二进制是 0100 0001~0101 1010 和 0110 0001~0111 1010
比如
01010001A，变成
01100001a

你可以直接翻转第六位，就是异或个 0010 0000

这个 0010 0000 在 ASCII 里面代表空格，所以你直接异或一个空格就可以。当然你得首先判断它是字符。

ASCII 当初就是这么设计的，大小写基本都是对称的位置。
另外虽然 ASCII 用来编码字符，但是对应数字那部分都是 0011 开头的。你把这部分 mask 掉剩下的就是字符所表示的实际数值。

兼容的 UTF8 也是一样的。不过正常来说，你要做一个完美的大小写转换，需要先判断 culture 才行。不过简单的可以就这么直接做了。

如果是兼容 ASCII 编码的字符串直接位运算就可以。

赶紧换吧。
前两天他们官方还在 V2 发帖说疫情期间免费，结果一群人骂。

他说的不是网络安全，是你存储介质。两个 RAID0 加上 iSCSI 比较容易炸。
@abbottcn

学了 Java 也不代表之前就是废的啊。
Spring 里面的 DI 容器，ASP 里面不是一样用？你前端各种框架不也是 DI 用的飞起？之前的 MVC，到现在 MVVM，前端框架不也都是有样学样吗。而且现在前端做的越来越复杂，你在后台开发实践的设计模式，面向切片等等前端不也都是能用得上。
再说你做 Web 应用，一个规模相似的应用不管用什么框架搭起来结构都是差不多的。你用 Java 这么做，换成 ASP 也是这么做。区别就是有的功能某些框架没有需要你写，或者实现起来细节不一样，不过大概的架构都是一样的。

一般不会直接拼 JSON 字符串的，都是通过库直接序列化某个对象。
JSON 库一般都可以配置或者重写序列化时的命名方法的，后端直接改一下就好了。

这算是最惨官方了吧。。。。。

@ginjedoad 话虽然是这么说，但真正开发过程中鸡毛蒜皮的事太多你根本就没精力去实现创意了。
建议你把推荐的这几个都跑个 demo，然后找个觉得最顺手的。个人项目刚开始还是不要让那些细节问题太过牵扯精力，不然没了热情就难以继续下去了。