@xylophone21 并不是 test 合并到 master,是 release 合并到 master ，release 是由多个或一个 feature 分支测试完成合并过来的

@xylophone21 标准 git flow 不适合所有公司，上面的流程是改造过的和 gitflow 是有差异的，比较适合大部分公司，大部分公司只有一套测试环境，存在同时提测多个功能，只能合并到 test 分支，这个是成本最少的，不可能一人一套环境测试，develop 这个分支在 a 流程是没有用的，test 分支已经具备该功能，新同事开发是基于 master 分支拉代码的，开发完才合并到 test ，这个时候就和 gitflow 流程很像了，但是修 bug 还是再自己的分支上面修改，然后不断地合并到 test 分支，直接测试通过，release 分支是到了预发布环境，这个时候一般 bug 都比较少了，测试会重新跑一次流程，这个时候可以直接在 release 上面修 bug,因为差不多可以上线了，开发分支基本没什么用了，测试在 release 分支测试完成了就可以把 release 分支合并到 master,这个时候代码才是最稳定的

可以看下我之前提问的帖子

来一个

b 很好奇，你说的 b 有什么优点，开发分支从测试分支拉出来，不觉得有问题吗。测试分支包含了其他人代码，你在测试分支拉出来开发完成，万一别人的代码有问题，你的代码一样有问题，暂时解决不了，上线就不干净了，有风险

c 更加无语，还是会存在一样的问题

a 流程没问题，也是最稳定的，预发布存在的一样就是 a,b,c 同事开发，同时测试，但这次发版我只需要 a,b 功能，这就体现了价值所在，只需要 ab 分支合并到预发布分支就可以了，
冲突在所难免，测试分支解决过的冲突，可能到预发布又要解决一次，尽量避免在同一个地方修改太多代码

做了一首自己曲子，还觉得挺好听的

jvm 看 hbase 源码吧，做了大量 gc 优化

可以把依赖库和核心代码分离出来，比如 sprintboot 可以把 lib 不打包到镜像，只打包核心代码就可以

不建议，踩过的坑无数，已经卷不动了，每一个技术都要知道原理，太累了

很简单，你试下用 left join 试试，where 会保留左边，但 on 左边也没有

学历硬性要求？

elasticearch,的 suggest 可以根据上下文来推荐搜索推荐词，要定时更新对应的热度，不是一直不变的

@PendingOni 顾名思义挣钱，朋友也只是锦上添花，但是日后想找用得着同事帮忙确实要点人脉，如果自己觉得不需要大可不必

@syc001 你说的对，如果在一起了，就应该认真对待这段感情，一开始我也这样认为，两个人会慢慢磨合的很好，但确实敌不过时间的冲淡，日子的磨平，很多事情并没有朝着好的方向发展，我是真的不够喜欢。确实累了

目前团队采用这种方式，我觉得适合大部分小团队，而且用了一段时间，非常好用
https://github.com/xiaolyuh/mrtf-git-flow-4idea

看我的帖子吧，我也觉得很累，聊得东西及其无聊，毫无营养，想培养个共同爱好也难，每天打电话就为了交差。

@zycz2p 感谢你的回复，只是电话了道歉了，各种对不起，还是不满意，我也真的不知道该说什么好了，也不知道怎么让她消气，她也不说话，往往这时候就沉默了，这个问题我真的不知道怎么解决

@KillPaul 因为确实是反思这段感情，觉得能不能挽救，因为不知道下一个也会存在不同的问题

@samohyes 是呢，这几天冷静思考下