@mysunshinedreams #4 Ribbon 负载均衡可以直接用 Feign 的啊。直接申明下就好了。

1. oracle 中有所谓的函数索引，即针对列计算出函数的值在生成索引。mysql 好像可以使用虚列曲线救国。

总的来说，代码写得好的都在刷 V2，而写的不好的都在哼次哼次写代码。。。

@tomoya92 #10 这里几乎不用考虑性能问题。

@Takamine #13 建一个私有分支修改代码，然后 merge 回公共分支？

我司历史遗留项目也有这种情况：所有的方法的参数都是 Map 或 Map<String, Object>。

这种方式编码的问题在于：
1 ）程序不运行起来不知道 Map 中有什么内容，即哪些 Key-->Value 对。
2 ）获取 value 值后需要强制类型转换，无法发挥 Java 静态类型的编程语言的优势。
3 ）更多情况下 Map 不仅仅用来传参，还会用来保存返回值。比如一个方法调用链 ：funcA(Map) --> funcB(Map) -- funcC(Map) ，这里面的函数可能存在会出现这种情况，funcB 中又修改了 key = foo 对应的 value 值，然后 funcC 中添加 key = bar 对应的 value 值，然后 funcA 中又读取了 foo 和 bar。

1、4 正确，2、3 错误。

屏蔽整个互联网的飘过

@guangtao8duan #140 房住不炒是 2016 年底提出来的，然后 2017 年房市还是火了一把。

@StarkWhite maven 负责编译测试打包，scp 上传，,ssh 远程命令重启。以上用一个脚本封装一下完全没问题。

@YourLord 这么裁员很傻的。对公司而言，不能确定哪些人，什么时候走，很被动的。

@StarkWhite 问题就变成了，个人小项目直接重启一下又不会太久，上啥热部署啊

小天神卡，五元月租，1G 一元

https://www.weibo.com/2124970203/HCaxxbEab?type=comment

分享个微博。

@leo108 #22 我只是按照楼主的现状说明过程的。实践中并不需要一个所谓的自己的分支，直接本地 company_trunk
分支开发就好了，并设置跟踪 origin/company_trunk。

你引用你自己的那句话并不正确，一直是可行的。问题其实就是本地分支落后远端分支，不管 rebase 和 merge 总是一直都是可行的。至于解决冲突耗费时间长短，那只能说明操作习惯有问题，应该及时和远端分支同步。

@leo108 #13 company_trunk rebase 自己的分支不是问题。你再看看前面的操作，楼主自己分支 也 rebase origin/company_trunk 了。只要 push 之前没有其他同事 push 更新 origin/company_trunk 就好了。即便有人更新了，直接在 company_trunk 分支执行 pull --rebase 并解决冲突就好了。

@arden #2 其实吧，只要玩的溜，Java 也能动态，可能你是没见过 Map<String, Object>满天飞的项目。

@leo108 #9 比如说本地分支 feature/abc 跟踪远程分支 origin/feature/abc。 在本地 feature/abc 上直接开发并提交到本地，执行 pull --rebase 可以将本地修改的内容在最新的 origin/feature/abc 最新的版本上衍合，然后执行 push 操作就可以，并不需要 push --force。 提交日志只有一条直线，所有开发者的开发活动像是依次顺序完成的，简洁明了。

@iConsLii #2 rebase 会丢失一些信息，但不是 commit log。另外顺序错乱也不会啊。

@leo108 #3 rebase 的时候不要变更已经发布到服务器上的提交不会有问题，而且服务器上一般都可以控制禁止 force push。