在执行 git push 之前，先确认目标分支和当前提交范围。 Git 本身变化不大，变化更快的是团队围绕它建立的协作方式。很多人现在说“用 Git”，实际指的不只是版本控制，还包括代码评审、分支策略、自动测试、权限管理和发布节奏。工具还是那个工具，工作流已经换了几轮。 第一阶段：集中式管理，规则清楚但动作偏重Git 之前，很多团队使用集中式版本控制。代码仓库只有一个中心，开发者先检出副本，修改后

浏览器里 47 个标签页没关，稍后再看里堆着上百条链接，收藏夹分了十几个文件夹，结果真正回看的，可能只有两三篇。 看到一篇“以后可能有用”的文章，先存；刷到一个“讲得不错”的视频，先收藏；遇到一个工具清单，先记进笔记软件。动作很快，心理上也会轻松一点，像是已经把知识留住了。 但大多数时候，留下来的只是“以后再说”。 收藏的问题，不在多，在错位收藏本来是用来延迟决策的：现在没空，先记下来，之后再处理

早高峰地铁里，盯着手机的人依然很多，但也能看到不少人闭着眼戴着耳机。 播客这几年又回到更多人的日常里。说“又”，是因为它并不是新东西。网络电台、RSS 订阅、音频节目早就存在，只是在很长一段时间里不算主流。短视频、直播、图文平台把注意力切得更碎，播客显得太慢，也太不合潮流。 现在，很多人重新接受了这种慢。 它填上的，是一块具体的空白播客变热，不一定说明大家更爱深度内容。更直接的解释是：眼睛先累了。

24 小时开机时，待机功耗 18W 和 45W 的整机，一年电费差距通常比跑分差距更值得先算清。 低功耗服务器选型，不适合只看“N100 很省电”这类结论。真正影响体验的通常不是单个 CPU，而是整个平台：主板、硬盘、电源、风扇和机箱通风，都会一起决定最终功耗、噪音和扩展性。 先把“低功耗”拆开很多人说低功耗，实际混在一起的是三件事： 待机功耗低机器大部分时间处于空闲状态，待机功耗最影响长期成本

当分支同时判断类型、字段和数据结构时，if/elif 很快就会变得难读。 模式匹配常被理解成“高级版 switch”，但它真正有用的地方，不是少写几行代码，而是把分支判断写得更贴近数据本身。Python 的 match、Rust 的 match，以及 Scala、Elixir、Haskell 中的同类机制，都在解决同一类问题：直接描述输入的形状，再决定如何处理。 它解决的不是简写，而是结构表达普通

curl -X POST https://<WEBHOOK_HOST>/hooks/deploy -H "X-Signature: <SIGNATURE>" 可以作为自动部署的触发入口。 这篇只讲一个最小可用方案：代码仓库推送后，向自己的机器发送 webhook；机器验证签名；通过后执行部署脚本；脚本拉代码、构建、切换版本、做一次健康检查。重点是能跑、能

凌晨 0:17，标题改到第 7 次，正文还是空的。 “先完成再完美”难，不是因为道理复杂，而是因为人很难接受自己先交出一个不完整的版本。很多卡住的时刻，不是不知道怎么做，而是总想再补一点、再顺一点、再稳一点，才愿意开始。 问题往往不在自律，而在太想一步到位。 难，不是因为懒完美主义表面上像认真，底层常常是回避。 怕做出来太普通 怕别人觉得不过如此 怕投入很多，结果还是不够好 于是人会停在一种看

在项目根目录放一个 Makefile，可以把 pytest、ruff、docker compose 这类零散命令统一成 make <target>。 很多人只在编译项目时见过 make test、make build、make clean。但 Make 更常见的价值，是把一堆脚本收成可重复执行的工作流。你不需要反复记 python xxx.py、bash scripts/deploy.

凌晨 03:00 的 cron 任务如果没有日志、返回码和告警，第二天很难确认它是否真的完整执行过。 定时任务最麻烦的不是直接报错，而是静默失败：进程退出了、输出被吞掉了、脚本只跑了一半、依赖服务超时了，但表面看起来一切正常。数据没更新，备份不完整，通知也没发出去；等到有人发现时，通常已经错过了处理窗口。 静默失败为什么难查因为定时任务执行时通常没人盯着。 手动执行时会看终端输出；定时执行时，很多

早上 9:17，聊天窗口弹出一句“有空回我一下”，很多人的一天就从这种打断开始。 异步沟通，就是不要求双方同时在线的沟通方式。邮件、留言、文档评论、任务卡片，甚至一条写清楚上下文的消息，都算。它和电话、会议、当面聊的区别，不是“慢”，而是不强制占用同一段时间。 远程工作和跨时区协作变多后，异步沟通成了很多场景的默认选项。它不是更高级的沟通方式，只是换了一种成本：少了即时打断，多了理解和等待。 异步