同样 eclipse ，jetbrains ，vscode 都会改为 eclipse keymap

确实用多了，不从实现角度思考代码细节了，给出一个解决方案提示，刷刷生成好代码，后面审视调测一下就 commit

@loong95 赞！解决问题了！

楼上说的都挺好的，比如任务拆分，禁止直接推送 develop，master 等。
建议你们小团队可以搞这样一个习俗，不管什么分支代码，只要在该项目内，比如是拉出的 feature 开发分支，那么保持提交点是一条直线，谁要是玩花了，请客喝水吃零食！
至于 feature 分支合到 develop 上冲突很多，那显然是模块任务划分不清，或者是需求不明，很多人在同时在改同一个地方。那是组织需求的问题了，这是属于是做不做。而代码的维护和管理是怎么做。

这就是我拥护 iOS 原因之一

这一波，都扒出来了，玩的 666

第一需要休息了。第二你需要一个娃。

中奖率这个东西，你做出来了，买家按你这个买了但是没中奖。你又没有让人相信的说法，就不好收场了。

快点去看医生吧，注意休息

挺好的，赞

Java 是很好的啊，PHP 也是很好的。其实 lz 的吐槽就是 PHP 刚刚转 Java 的感受，终究还是没熟悉的问题，熟悉了 Java 的开发思维，处理模式就事半功倍了。

这样的技术积累对公司是非常好的。而且还开源这么好的项目。赞

推荐 scrum 的时间预估方法。没有扑克，就用一张纸来写，大家写完了，再拿一起出来看。每个开发说说这个任务自己为什么要评估这个时长。大家一起讨论，当前任务就会有一个相对合适的完成时长了。

同时项目负责人需要注意几点
1.任务拆分需要精细。比如内容列表展示，就只是列表展示。不包括列表上的搜索，其他附属功能。但同时不能太细，比如分页还作为一个任务。
2.注意每个人 story 的时间，给出你的建议时间。同样的功能，一个人很熟悉与一个人不熟悉，给出的时间是不一样的。
3.项目冲刺期间，每日工作量是否完成要确认。某个人如果进度落后，可能是遇到困难了，或者任务分配太多了等。项目负责人需要及时给予帮助，协调解决。如果任务分配多了，就拿出一些给进度较好的人。遇见项目难题了，及时提出来，大家来攻关。

但如果是项目目标不明确，需求变更，或者方案有误。那就是另外的范畴了。

bootstrap,adminlte

论秀女朋友的另一种形式

还是规避这种 case 比较写法吧，可以考虑用这个 strcmp 比较，类型自动转换为 string

php 一路走到头，当然给你一个 null :-)

性格极端，内心善良。希望他加油。