dcsuibian

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

@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

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

WebStorm 不是现在非商用免费了么，那你可以都试试，又花不了你时间
反正我是从 VSCode 跳到了 WebStorm

要不你问问 ai

便利性和安全性你总要做个平衡，对我来说是安全性更重要一点，所以我不介意把密码设的长点。
你要是想更方便，那把密码设短点不就行了

忍了