这个跟操作系统无关，是主板管的，仅取决于主板硬件设计和主板驱动。

首先，a 和 b 都是临时特性分支，他们在合并的时候无需区别对待。所以下面的步骤只列出 a ，b 的操作步骤是一摸一样的，a b 的顺序也没有要求。

非线性历史，传统合并方式：
checkout dev
merge a
如果有冲突，以新提交的方式解决冲突；但是如果 dev 分支是受保护分支，就要在额外的临时分支中解决冲突，然后再合并临时分支。

准线性历史，变基合并方式：
1 、checkout a
2 、rebase dev
3 、如果有冲突，在 a 上解决冲突
4 、checkout dev
5 、merge a
6 、此时如果有冲突，反转第 5 步（通过 reset --hard 方式），然后回到第 1 步继续

此外还有完全线性历史的压缩合并方式，但是这个基本不会用到。

以上合并方式，虽然步骤很多，但是如果在界面操作 Pull Request 或 Merte Request ，就很简单了。


不建议 cherry-pick 方式，因为你的 dev 、a 、b 是有共同祖先的的，没必要用 cherry-pick 。

@zed1018
@ErnestSu
重点不是是否 catch ，是 catch 之后不能即不处理又不 throw 。

try (InputStream input = new FileInputStream("src/readme.txt")) {

}catch (IOException e){

}

这才是正确的用法，因为 try-with-resources 只是自动调用 close （以及将 finally 当中抛出的异常转移到 try 当中抛出）, 但不隐藏异常，对于 IOException 这种受检异常，你必须自己处理。

他可以不批你调休，你也可以到点就下班、不接受任务，你还可以直接向人力资源部投诉。反正这种人也是没办法调和的，直接交给公司处理。当然如果公司也摆烂的话，在国内就只有即时止损这一条路了。

多看书，少看短视频。第一，时间单位和基准时间都是有国际公约的。第二，误差绝对存在，但误差会被控制在可控范围内，现在的时间基于原子钟，误差是小于纳秒级别的。

买 8 ，或者蹲 10 。不要蹲 9 ，9 可以确定是 12 代，虽然性能提升很大但是不稳定。另外 Intel 的 CPU ，寿命要按照 2 年看待，能同时挤牙膏和淘汰飞快的，也就这一家了。

翻译并不是一件容易事，专业翻译成本很大，所以官方想支持中文很可能有心无力。编程语言在历史上官方支持非英文的，印象中只有 SUN ，就这卖身之后立马就断了中文支持。目前仍在官方支持中文的，估计也就剩谷歌了，连微软的中文文档都是大量的“本篇翻译可能不准确”。

既然是已经用了 Spring ，你好像还用了其他的 AOP ，那么 var executor = executorConfig.asyncServiceExecutor(); 弄出来的 executor ，就不一定是前面代码上的 “new ThreadPoolTaskExecutor();”。或者说，executor 对象的类型，不一定是 ThreadPoolTaskExecutor 。这时候用 ThreadPoolTaskExecutor 的 hashCode 和 toString 方法推断的测试结果，可能不是实际结果。

用了 4 年 surface pro 的来告诉你，6 寸手机+台式机（全尺寸键盘+显示器），才是最好的娱乐生产两不误。

平板也不是没用处，只不过用到他的地方不广泛——比如说用在生产上的车间开发板，用在娱乐上的移动点餐台（然而这个实际上没有纸质菜单+手机电子点餐同步使用更好用）。

编程语言也是语言，国内设计语言，你是想……

对于你的标题：Spring Cloud Config 。

对于你的内容，跨服务不要共享一个数据库，服务内跨模块不要分离人工配置（默认配置可以分离）。

开发成本上举一些简单的例子，结对编程或者代码评审，全覆盖单元测试，这些随便上一个就得让开发时间翻倍。而国内盛行的是只看你有没有在规定的时间内完成可运行程序。

跟 Java 无关，国内是常态。这跟办事风格有关，国内压根就不留代码质量改善的时间。代码质量别说提高了，就是维持，也很占开发成本，并且这占得还是团队成本而不是个人成本（意味着 10 个人中即使 9 个人愿意加班维持代码质量，只要有 1 个人不原因那整体质量就没法维持）。

就拿阿里巴巴规范来说，看着很规范是吧，但你要么 007 要么写出来看着遵守规范实际上质量糟糕的代码（并且还得 996 ）。可以比较以下阿里巴巴 Java 规范跟 google java 规范，你会看到在规范之外的不同办事风格。

@dcsuibian 你到现在还没发现问题吗，同一个 Unix 时间戳值，在读取 /显示的时候，不同时区是不一样的。

你局限在数值的不变上，但一个显示值随时区变化的数值，压根就不能成为数据，完整的数据，要是数值+时区。这就是数值型时间戳必须额外带时区，或者说数值型时间戳跟时区相关的原因。

你也局限在了 Java 上，java.util.Date 及其相关类的内部值，是存储的自 1970-1-1T00:00:00+0 到现在的毫秒数，但这只是 Java 的规范。Unix 时间戳不是国际标准，其他语言、数据库都可能定义自己的规范，比如有的语言会把时间戳定义为当前时区自 1970-1-1T00:00:00 到现在的毫秒数。结合使用的时候就容易出坑。

@dcsuibian System.currentTimeMillis() 生成的是 UTC0 时间戳，隐式 UTC0 ，不代表没有 UTC 0 。这个区别很重要，因为有些工具生成的当前时间不是 UTC0 的。

试试 Mysql 下执行这个 SELECT CURRENT_TIMESTAMP(),LOCALTIMESTAMP(),UTC_TIMESTAMP(),NOW() FROM DUAL;

另外实际上只有 UNIX 时间戳才是从 UTC 1970 年 1 月 1 日 0 时 0 分 0 秒起至现在的总秒数，ISO 8601 时间戳就是年月日时分表时区的组合。

@dcsuibian #21 并不是，你所谓的无关，其实是隐含了 UTC 0 。数值型的时间戳，都是基于 UNIX 时间戳，而 UNIX 时间戳的定义是：从 UTC 1970 年 1 月 1 日 0 时 0 分 0 秒起至现在的总秒数。单独的一个数值，不是时间戳，带上时区，最起码要隐含 UTC 0 ，才是时间戳。

其实时间戳最大的问题，不是带时区，而是这个时区怎么带，根本没有统一规范。有的总是存储 UTC0 , 有的读写时跟随随环境变量（会发生因不同时区导致的读写不一致问题），有的将时区跟数值一起保存。

@MuXia #17 若不考虑国际化，就用 java.time.LocalDateTime 对应 Mysql DateTime ，只要保证 JVM 、Mysql 、JDBC 连接配置都是东八区，其他时候就都不用考虑时区问题。

@MuXia 不要用单一的数值类型存时间戳，那实际上隐式存了一个 JDBC 时区，该时区依赖于 JVM 时区和 JDBC 驱动，当 JVM 时区、JDBC 驱动、或者只是 JDBC 连接配置（ Mysql 就是个典型）发生变化的时候，会发生很难处理的时间偏移问题。要存时间戳，必须用数据库的带时区 Timestamp ，或者数字列+时区列两列存储时间。