（续）
总之 git 本身也不是一本史书，git 是一个 Source code management ，这个软件的核心目的是管理源代码，最终这个管理是要为软件开发和发布服务的，对软件开发和软件发布有益的做法就是正确的做法，如果一种做法导致软件开发变得困难，这种做法就应该被认定为是不合适的。如果提交历史一团糟，这个一团糟到底是改善了软件开发环境，还是影响了软件开发环境，你这样去判断，就能知道保留一团糟的历史是否是一件正确的事情。不要为了准确而准确，为了记录而记录，这是一个软件开发工具，不是史书编撰工具。

@dcsuibian #19
这两种观点并不是完全冲突的。
保留历史的细节程度和历史的尺度有关。比如说你遇到了生产事故，需要写事故处理记录，你当然要把每一分每一秒每一次事件都记录下来。但如果你是在写上下五千年的史书，那会有人关心你某一天下午 2 点的时候打翻了一杯水吗。
我司在开发的比较大的项目，尺度基本是上下十年，一个工程师一个月交两个功能，一个 team 下 50 个人一个月就是 100 个功能，一年 1200 个，十年 12000 个，假如平均实现一个功能有 10 个提交，那就是 12 万个提交，你光是要查两三个月前某个提交的 bug 就得翻不知道多少页才能找到，就非常不方便。这还是 master 分支，你要再加上 release 分支测试分支就更多了。所以我们要求所有合并到主线的提交都是 squash merge 。开发分支提 PR 的时候随便你多少个提交，最后全合一起。
如果是小项目，比如说 one man 项目或者一个 team 里两三个人协作，那可以把提交做得细一点，合并 feature 分支的时候用 merge commit 就没问题。

记录实际发生过什么这个也是有粒度的。严格来讲，每一次输入删除都是一次更改，但你肯定不会觉得每打一个单词都要提交吧。那么到底打多少个单词才需要提交一次呢，删了多少代码才需要提交一次呢。这个粒度把控，不同的人也有不同的观点的。

先 squash 再 rebase 再 merge 就行。
每一个操作都有自己该用和不该用的场景，正确的做法是在正确的场景用正确的操作。

@zhucegeqiu reddit 上的商家。

不如拿去分析蛋白质或者找外星人？

昨天刚到手 5 片希捷 18T ，里面 chia 图文件都还在，现在在 badblocks 扫盘。除了小时数以外其他基本是新的，写入量就是 18T ，读取不到 1T ，2021 年 12 月填的盘，保修到 2026 年年底。矿盘数据不清零的话还是可以买的，14T 以上质量都很好。

做涩图带盈利抓到是要入刑的，哥们儿三思啊。

因为你用的虚拟号码所以不让你选号？我 Google 上随便搜一下就搜出原因了。

@NevadaLi #9 所以说你这个测试没法反映真实世界的情况。
真实情况就是不是每个人都是运维，每个人都会追踪 EOL 。
你#15 里的大话谁都会说，但不是每个人都能做到你说的那些。

你当然可以说，开车只要小心点，就不会出交通事故，结果你还是和别人擦了，那我还能说什么。
你当然可以说，只要保持良好的作息，就不容易生病了，结果你还是要熬夜，那我还能说什么。
你当然可以说，写代码的时候只要认真仔细，多写测试多写文档，就不容易出 bug 了，结果你还是懒得写测试和文档，那我还能说什么。

那我还能说什么（摊手

再说了，服务器系统也不是随时随地就能重启的，你上面跑着程序呢，每次周二出补丁你都不顾一切立刻装完更新重启？有没有试过打完补丁系统起不来的情况？连微软自己都知道这玩意儿没那么靠谱，所以重要服务都有高可用顶着，域控还要做 dc1 dc2 双机互备，两台机器轮流更新呢。你有没有想过 0day 漏洞从出现到有补丁到补丁推送都是要时间的？

真正注重安全的企业，系统登录接口都是放在 VPN 后面的，VPN 都有硬件 Key 做认证的，你都暴露在公网了，那我还能说什么？（

一个月不行，你得开两三年，等哪天爆了新的 rdp 0day 漏洞了你别急着打补丁，然后再看看有没有人能干进来。

证书登录？这是啥使用环境啊？

@GaGaGood 华州，一年 75 美元。

我这早就有电车附加税了，哪怕是不能充电的混动一样收电车附加税。

电子辣鸡，就当电子辣鸡来用就行了。
寿命完全看天，可能两个礼拜坏了，可能两年还坚挺，谁都不知道。
这种二手老硬盘我这一大堆，没清零的，都当辣鸡扔了。

个人喜好不同，有些人习惯设定好自动续期然后放着不管，有些人喜欢一年过期一次等人提醒了再想起来。

想知道 386 电脑上低级格式化长什么样的可以看这个视频：

MFM 磁盘驱动器修复、低级格式化和测试教程
https://www.bilibili.com/video/BV1kc411378G/?t=745