你的这两种方案都有一些问题。

两个方案都没有版本的概念，这样会导致你本次功能上线出现问题后，无法正确回滚至上一版本。方案二不应该在测试后再进行代码合并，测试的永远应该是最后要上线的代码。

我公司通常这么处理的：

- 从 master 拉取 release-xxx 作为本次的发布分支
- 再从发布分支中 release-xxx 拉取开发分支 feature1212
- 至于你两种方案中纠结的到底是两个人共用一个开发分支，还是各建一个，我的建议：你们就两个人，没有必要增加分支复杂度，直接公用一个开发分支即可，至于开发中遇到冲突，可以通过频繁的 pull/push 来解决
- 你两种方案中的 dev 分支我认为也没有起到效果，首先测试代码应该和要发布的代码完全一致才有意义，你这里的 dev 分支没有注明检出来源，feature1212 merge 到 dev ，无法保证 feature1212 和 dev 代码一致。正确做法是你应该 feature1212 合并回 release-xxx ，用合并后的发布分支直接测试
- 测试完成后发布分支 release-xxx 部署线上发布
- 发布后出现问题，如果要回滚上一版本，那么直接拿上一版本的发布分支（你这里是 master ）部署线上；如果要紧急修复，那么从 release-xxx 中检出一个 release-xxx-fix 去重复上面的过程

目标 14700 千卡，坚持了一个月，最后几天功亏一篑了，今天还差 1217 千卡

所以讨论了半天，还是最熟悉的才是最有生产力的

刚了解，下班回去下载看看

我的个人经验就是选择普适性或者理论性的选题。
之前同事讲过芯片制作的过程，挺有意思的。我之前也讲过信息论相关的概念，感觉也还不错。

不破不立! 7777777

燃脂 14700 千卡

下单了辆自行车，希望 1024 年能到手

@spadger #91
@Ziya #95
推荐一下 beancount 。我之前还写了一个给 beancount 提供 server 服务的 node 应用，可以参考下： https://github.com/BaoXuebin/beancount-node-server

感谢分享，原来浏览器设置里的搜索引擎是这么用的

我之前曾经尝试把业务逻辑实现改为链式调用的形式，看上去是舒服了一点。
TaskWrapperProvider.init(wrapperMapper).createWrapper(taskId).signIn(signParams); // 任务签到的需求

微服务的目的就是降低服务之间的耦合性，从开发的角度讲，一个业务需求只需要调用 C1 和 C2，就不应该调用 A，从而达到和 A 解耦的目的。你这种先拿到 A 再去调用 C1 和 C2 的方案是为了性能而丧失了服务间的解耦，得不偿失。

我有这个需求，然而我自己之前也写了一个 https://clip.xdbin.com

之前尝试六点起作 morning page，坚持了一天

我的数据库之前也被删库了，备份他们是不可能备份的，看日志只是执行了几个 drop 命令。

我觉得你导师很负责，分享确实是让新同事快速融入的一个方法；但公司制度很操蛋。

周末不加班

https://wx1.sinaimg.cn/mw2000/e2f565c4gy1grml3vn93nj20qn05hjro.jpg