dcsuibian

居然不是杭州

@dilidilid 所以我说在同等便利性上已经做到最好是没错的。当然你说的能给用户更多的选择也没错。

但我想强调的是，当出了这种事故，第一个应该是认识到自己安全意识不足，而不是责怪他人。举个例子，如果我使用了 Chrome 来保存密码，我的电脑中了病毒导致 Chrome 中的密码被盗，我就会首先反思自己。因为我知道安全性和便利性是有平衡的，我知道我在得到一定的便利性时损失了怎样的安全性。而有的人就不知道。

这里面的重点在于，谷歌如何做好这个工具只是他的社会责任，而有没有安全意识是关系到你的切身利益。

puppeteer

@dilidilid 你说的这个东西明显有便利性上的损失
我说的是在对应的便利性上，Chrome 的安全性上已经做到最好了。

不会，我觉得会提高。因为你会看到别人是怎么写这个的东西，或者给你其他的解决思路

@msg7086 你这个是工作流和提交的历史粒度的问题。

我没有把他当成史书来写，只是我觉得提交历史的整理不应以“模糊真实变更”为代价，过于简化的历史可能反而增加复杂性。

具体到你的场景，如果是我的话，我会创建一个中间分支，比如`dev`吧，将个人分支合并上去的时候用`merge --no-ff`，这样这个分支上看起来就只前进了一个提交。

当然具体选择什么样的工作流随你，你觉得什么样的工作流适合你都行。我只是说我比较喜欢`merge`。

至于什么时候提交：

我的观点是一个提交实现一个逻辑单元：

每次提交都应对应一个独立且完整的逻辑改动，例如：

- 实现一个功能。
- 修复一个 Bug 。
- 添加测试用例。
- 改善代码的性能或样式。

嵌入式 Windows 不是精简版 Windows ，是为了嵌入式场景优化，而不是为了游戏优化的。而且嵌入式 Windows 好像也不流行吧。所以如果拿 Windows 作主机的话，可能还是得标准版。标准版的就不便宜了。而且就算能用嵌入式 windows ，授权费也不会比 Linux 更便宜。

我觉得 V 社可能有以下几点的考量：
1 、成本控制，上文所说地授权费嘛。
2 、控制力，定制操作系统使其可以自由地设计功能、用户界面和系统更新流程。
3 、竞争关系。当初 2016 年微软商店刚出的时候，有不少人就担心其和 Steam 的竞争关系。
4 、性能。Windows 是通用操作系统，很重，性能优化不是关键。

V 社其实 2014 年就有做过主机了，那时候就是基于 Linux 。估计想和 win 脱离已经很久了。

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

以上内容来自《 pro git 》，个人更赞同第一种观点。所以我比较讨厌 rebase 。

我比较喜欢用 git merge --no-ff --no-commit

直接存字符串，对运维最友好