@taobibi RAID5 热备做大死。

硬盘是可以修的，但是原则上还是以保修返厂为主。
硬盘是存储数据的介质，数据是主要的，硬盘只是消耗品。你要靠谱的可以买企业级，但是凡是硬盘都有可能坏，没有保证多久不坏的硬盘。硬盘的寿命也是平均寿命，没有保证寿命的。再贵的硬盘也有可能半年一年坏掉，便宜的硬盘也有连续跑七八年不坏的。

对于影音内容，考虑单盘+SnapRAID 结构。这种结构下就算损坏多块硬盘也不至于整个阵列一起完蛋，没坏的盘上的数据都是完整可读的。
对于备份，可以考虑 GSuite Drive，月付 12 美元，无限空间，虽然国内速度不快，但是好歹用作备份，只有硬盘坏了才会用得到，平时只要用 rclone 增量同步即可。

M570。顺便请自备微动、电烙铁等工具，过保以后可以自己换。

Git 包含两部分，一个是底层的文件结构，也就是 .git 目录和里面的数据。
另一个是上面跑的命令行程序。
Git 强大就强大在他的灵活性上，也就是前者强大；而后者功能虽然强，但是结构非常乱，适合被脚本、软件调用，而不是直接面对用户。

他的对手 Hg 则正好相反，Hg 命令行功能很清晰，但是底层 .hg 功能太弱，基本概念照搬 SVN，分支不方便，Rebase 不方便，适合那种一锤定音一次提交就再不用改的人。Git 则是允许用户犯错，错你随便犯，反正都能修回来；代码尽管随手提交，反正后期都能 Interactive Rebase 回来。

我怕的就是把 Git 当高级版 SVN 用的。

@rockyou12 Git 这么好用的工具，出错了又怎么样？ push -f 又不会丢数据，覆盖了有用提交直接从 reflog 里挖出来 push -f 推回去就行了，为什么要个个是神 100%不出错？出错了才能吸取经验才能进步，就是因为怕犯错才天天这也不敢用那也不敢用，Git 用了 10 年也就和刚上手一两年的人一个水平。

而且相反的，不允许-f 来纠正错误，让程序员提心吊胆生怕不小心推错东西一失足成千古恨，才是所谓的「你团队个个都是神能 100%不出错」。

至于你说的 reset revert merge rebase 瞎瘠薄命名的问题，我只能说，找个好点的客户端吧。不要让工具去限制人的发挥。

命令行 Git 功能参数太乱 -> 复杂 Merge/Rebase 容易丢代码 -> 不允许 push -f -> 程序员怕推错提交而自裁提交数量 -> 不再频繁提交与推送

不知道别人怎么样，反正要是哪天不让我用 push -f 了，怕是我连维护手头的那堆开源软件都不知道怎么操作了。

穷举本来就是最后一种方法，哪有防穷举这种东西。
比如我问你，我一年工资多少钱，精确到分。于是你从 0.01 开始穷举，一路往上到几百，几千，几万，总有一天能穷举出正确答案的。
你说的可能是防规律遍历。

敏捷开发快速迭代对设计的要求有所降低，不画 UML 不做详细设计方案但是大体上的思路还是要有的，否则写代码就像无头苍蝇一样乱撞也不是个办法。

后端拿掉就等于没有了后端权限控制，拿到 ORM 就等于可以往数据库里随意写数据了。不知道这个怎么解决。

@rockyou12 我们就是这么管理项目的。Rebase 了 Push 上去是为了做 Merge Request Peer Review。不做 Peer Review 直接 Squash 成一个 Commit 然后就往主干上塞？我可谢谢您了。
而且我们要求组员都要频繁提交频繁 Push，完成一处修改就 Commit+Push，以避免本地副本意外丢失。
不知道这些被很多人推荐的项目管理实践怎么到你眼中都变成没必要的东西了。

对我们来说，绑着程序员不让他们自由地利用工具来完成项目才是个项目管理问题，有啥好说的。

@Love4Taylor Equuleus 和 Libra 都还遥遥无期……

@rockyou12 开发不一定能做到每人一个分支。
而且每人一个分支 Rebase 一样要 Force push，只不过 Push 的不是 Master/Dev 而是 Feature 分支罢了。

要玩原生的话，LOS，ASOP Extended，RR，PixelExp，不都是吗。

拷进去又不会检查文件是否正常。拷出来才会遇到读不出数据的情况。你 U 盘是正规渠道购买的吗？

不如试试 C 井？

@zolo 账单自然月月底生成。
理论上如果你 26 日创建了实例，就应该只有 26-月底之间的流量额度，而不是整月的额度。
也就是说，并非 1TB 而是只有比如说 150G 额度。
具体执行情况还是要看他们内部算法了。

@kaneg 我个人的观点是，对版本管理系统而言，只有有用的操作才应该写在历史记录中。
比如写某个模块，程序员尝试了 20 种不同的方法，最后把正确的方法提交进了版本库。如果每一个操作都记录进去，那么就等于是时间线上出现了三四十次提交，审核代码时，这之前的那么多次尝试你是审呢（浪费时间）还是不审呢（会有漏网之鱼）。还我的话，宁愿把代码整理干净，既方便审核，又方便回滚和追溯。
以及我认为，Force push 应该是每一个程序员都应该掌握的功能。连 Interactive rebase 和 Force push 都做不到的程序员，我不认为是完整掌握了 Git。