nothingistrue

4000 这个挡位，不要锂电池就雅迪，想要锂电池就小牛的非智能系列（基本上都是磷酸铁锂不是三元锂）。可以加钱的话就考虑这俩品牌的智能系列，小牛的智能方案最成熟，但雅迪的工业化程度最完善。

@dxatgp02 #3 先把 public 、private 、protectce 、default/friend 这几个可见范围搞清楚再说。max 声明称 public ，就可以用你的第二种写法。只不过 public 的字段，要比繁琐的 getter/setter 不便处更大。

这是小贷（包括京东金条和各种呗这种互联网小贷）申请时候的查询。如果没有其他记录那就是只查询没后续，所以这个银行那里的一般查询，是查不到你的。高级查询，要查申请但没成功的记录，才有可能查到你。

基本可以确定你被小贷的虚假宣传给坑了，或者没仔细看协议就授权人家查你征信。只有偶尔一次的查询记录的话，除非遇见特别小心眼的银行，影响都不大。

@magic3584 #36 不是直接 push --force ，是先要确定那个人本地的仓库跟回滚前服务器上仓库是同步过的，才能让那个人 push --force 以覆盖的方式恢复服务器上已经被破坏的仓库。

@magic3584 你这一块，我建议不要自己搞了，搞不定的，还是先找别人帮你处理了。后面有时间了花上半个月去看看 https://git-scm.com/book/zh/v2 ，git 才能入门。

@magic3584 #24 假如远程 master 的 提交顺序是 a,b,c,d,e,f,g ，被回滚到了 d ，变成了 a,b,c,d,e,f,g 。这时候 d 之后的提交 e,f,g 就都丢失了。然后丢失的不光是这些，因为这个 e,f,g 在做过 pull 的所有人的本地还是存在的，这时候这些人本地上的 master 分支，跟远程的 master 分支，是混淆的。

实际上中央服务器被回滚，相当于有人做了 push --force ，是特么相当操蛋的行为。这时候要是有人正好在服务器出问题前做过 pull 还好，他那里再做一次 push --force 就能恢复过来。但要是没有这种正好情况，那么在 d 这个提交时间点之后的所有提交，不管是本地还是中央仓库，不管有没有推送过，都成了离线的提交，需要手动处理才能搞回去。

在开发完整软件 /项目 /工程上，JavaScript 确实该入土了。但是在开发脚本上，JavaScript 还是很好用的，比如说 Kettle 上的 javascrpt 脚本就比 java 脚本好用。

JavaScript 的最大问题是它本来只是个脚本语言，却被人用来当成了工程语言，最早拿 JavaScript 来开发客户端应用（貌似是 ExtJS ）的人，应该被拉出来鞭尸。

@magic3584 #18 先 fetch ，你现在本地仓库上的远程仓库引用 origin/master 跟真是的远程仓库 master 分支可能都不一样。这事，建议找熟手帮你做。没有话就别 pull 了，只能手动复制粘贴。

@magic3584 #15 远程分支被回滚，说明远程分支已经被破坏了，这时候就不能做任何 pull ，否则你本地也要跟着被破坏。远程分支回滚后的那个 Head ，它之后的（在回滚前）所有提交，不管是本地的还是远程的，都被搞废了。你们本地需要先留着当前仓库不动，另开位置重新 clone ，然后通过补丁或者复制粘贴，把本地晚于远程 Head 的提交，手动重新提交上去。当然，也可以用 pull --rebase ，它本质上是 rebase -i ，前提是已经对 git 操作尤其是 rebase 相当熟练。