@pagxir 没有 push 的 commit 修改很正常，没有任何方法可以在不修改 commit 的情况下满足 lz 的需求

正确答案：Rebase 交换 commit 顺序，然后指定 commit id push
最佳实践：每个 feature/bugfix 都是一个单独的本地分支，都往同一个远程分支 push，push 前用 rebase 同步远程分支即可


正确答案往往不是最佳实践，git 的特性就是轻量级的本地分支，如果不爱用，无疑是浪费了 git 最大的特性

没影响，有正规工作贷款没任何问题

别听网上的人瞎说

@abmin521 我说的也没有排除系统盘

@abmin521 分布式块存储扩容不难，国内阿里的云盘，百度的 CDS 都支持在线扩容，架构上没啥难点。

OpenStack 中的 Ceph 也可以在线扩容

技术上 EC2 并没有超过 OpenStack，所以你去看 OpenStack 就好了

Mac 是自动调节的，而且效果比 Windows 好

这个验证很简单，你拿一个 MacBook 装双系统，然后分别进行同样的工作负载续航测试。

Windows 差不多要短一个多小时

window 这种常用词，申请商标应该比较麻烦，冲突的不少

这个很难说明就是维修带来的损坏吧

更可能是手机质量不好，出现了其他故障。这个过保自然不会免费维修，只能怪你运气不好

不会没关系，但是短期学不会证明学习能力太差

短期指的是一天全职学习，或者一周业余时间学习

程序员和语言描述能力很差没有必然关系，理解楼主的心情，但是不要给整个团体贴标签。

如果用的是 Chrome，应该是关闭了 Flash 的展示，在地址栏 URL 前面点击设置下 Flash 为允许就好了

没办法，自认倒霉吧

HTTP 中间人可以为所欲为，只用来抓 cookie 简直就是大材小用。

就好比发一个贴，我能空手切 1mm 的豆腐，结果用的是菜刀，这有什么好吹的。

@helionzzz 静态页面、查询功能这种难度就太低了。从 lz 可以看到 12306 的余票不是实时的，是有 cache 的，这样别说百万并发了，亿万都没有什么难度。退票的限制太多，真正的退票请求也很少。

最难的就是订单处理。

@bk201 复杂度是一回事，并发度是一回事

我说的只有一句话『 12306 的并发也顶多百万量级就够了』，你不用转移这个话题

铁路春运，日发送旅客峰值一亿左右，全天有 20 个左右放票时间点（不同车站不同），考虑到不均匀，单个时间点应该有 1000w 张票卖出，再考虑到票不是预售期刚开始就全部卖出，那么在预售期当天的单个时间点，卖出的票最多不过几百万张

而 12306 现在抢票都是把请求先塞到队列中，然后顺次出票，出票时间经常长达好几分钟之久，将数百万分布在好几分钟 内，你说每秒能成交多少张。

@helionzzz

@helionzzz 如果纯订单逻辑，可能百万并发都不到。不理解的要么是不懂什么是并发，要么是不懂数学。

alipay 去年双十一交易峰值每秒也不过 26 万笔而已