共 109 篇相关文章
科技爱好者周刊第401期整合创业见解与技术动态。创业部分引用保罗·格雷厄姆观点，强调通过高增长率（如月增15%）和庞大市场实现财富积累，举例说明指数增长潜力。技术文章介绍HTTP新增QUERY方法，作为带数据体的GET请求，不缓存参数；分析JWT令牌适用场景，建议仅用于跨机器状态转移而非用户登录；SQLite项目拒绝外部PR，因长期维护成本高昂。工具推荐Lore版本管理系统，优化二进制文件处理；DNS Pick命令行工具帮助优选DNS服务器；GitFolio提供轻量级Git仓库管理。AI工具包括Fishword背单词插件和OnePagent智能体工作台，增强开发效率。资源部分涵盖网页游戏和星空模拟器，文摘回顾米定义的科学演进。文章融合创业策略、技术更新与实用资源，为开发者提供多维度参考。
本文提供了从零开始重建macOS开发机的完整可复现环境初始化流程。首先安装Xcode命令行工具和系统基础工具链，确保编译和开发基础。接着配置Homebrew包管理器，简化软件依赖管理。设置Oh My Zsh及自动补全插件，优化终端交互体验。基于gpg-agent统一托管SSH和GPG密钥，实现Git提交签名的集中管理，提升操作安全性。多语言运行时管理采用版本隔离策略：使用GVM管理Go版本，Miniforge处理Python环境，nvm管理Node.js版本，以及Bun作为JavaScript工具链。每个步骤均提供可执行命令、真实日志输出和验证方式，确保环境正确性。最后补充新设备到手后的系统初始化清单，涵盖隐私设置和基础配置。该方案强调可复用性和迁移性，适用于开发者快速搭建一致开发环境，支持设备更换或灾难恢复场景。
本文详细讲解了在不使用 --mirror 选项的情况下，将源仓库的所有分支和标签拉取到本地并推送到新远程仓库的操作方法。首先，必须确保源仓库是正常的可工作仓库，而非裸镜像仓库，以保障数据完整性和后续可用性。步骤一：使用标准 git clone 命令克隆源仓库，创建本地副本并初始化默认分支。步骤二：通过 git branch -r 命令列出所有远程分支，以便识别需同步的内容。步骤三：执行 git fetch 命令获取所有分支和标签数据，确保本地仓库与远程完全同步。步骤四：为每个本地分支设置上游跟踪信息，并使用 git push 命令逐一推送到新仓库，注意保持分支名称一致性以避免冲突。这种方法适用于仓库迁移、团队协作或备份场景，能完整保留代码历史和标签信息，避免了 --mirror 创建裸仓库的限制，提供更灵活的开发环境。通过实践这些步骤，开发者可以深入掌握 Git 多分支管理技巧，提升代码维护效率。
Git 中恢复文件到其他分支状态有两种常用命令。假设当前在 main 分支，希望将 path/to/config.yaml 文件恢复到 dev 分支的状态，可以使用 git checkout dev -- path/to/config.yaml，或 git restore --source=dev -- path/to/config.yaml。这两种方法本质上相同，都通过指定源分支和文件路径，将目标文件从 dev 分支覆盖到当前分支，而不影响其他文件或提交历史。这种操作适用于版本控制中的局部文件恢复场景，例如在合并前同步配置或修复特定分支的代码差异。git checkout 是较旧的命令，而 git restore 是更现代且语义明确的替代，推荐使用后者以提高可读性。实际执行时，Git 会从 dev 分支提取文件内容，并更新当前工作区的对应文件，无需切换分支或创建额外提交。这两种方式都强调了分支独立性和文件级操作的灵活性，有助于维护代码库的一致性和可追溯性。
在CI/CD环境中，多个进程或脚本并发操作同一个Git仓库时，常因元数据损坏或锁冲突导致“unable to read tree”错误。Git并非为高并发本地操作设计，因此需要解决并发问题。有效的方法是通过加锁机制让Git操作串行执行，flock工具为此提供了简单高效的解决方案。 flock属于util-linux套件，大多数Linux发行版已预装，若未安装可通过apt或yum等包管理器安装。macOS默认不包含flock，但可通过Homebrew安装兼容版本。在CI服务如GitHub Actions中，可在任务步骤中预先安装flock以确保可用性。 使用flock时，基本语法为
Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。
我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多：
通常 Code Review 有两种场景，一种是公司内部，还有就是开源社区。
先说开源社区，最近也在做 cim 项目里做 Review，同时也在 Pulsar、OpenTelemetry、StarRocks 这些项目里做过 Reviewer。
以下是一些我参与 Code Review 的一些经验：
在提交 PR 进行 Code Review 之前最好先提交一个 issue 和社区讨论下，你的这个改动社区是否接受。
我见过一些事前没有提前沟通，然后提交了一个很复杂的 PR，会导致维护者很难 Review，同时也会打击参与者的积极性。
所以强烈建议一些复杂的修改一定先要提前和社区沟通，除非这是一些十拿九稳的问题。
一些大型项目往往都有完善的 CI 流程来保证代码质量，通常都有以下的校验：
如果一个 PR 连 CI 都没跑过，其实也没有提前 Review 的必要了，所以在提 PR 之前都建议先在自己的 repo 里将主要的 CI 都跑过再提交 PR。
这个在 Pulsar 的官方贡献流程里也有单独提到。
同时在 PR 模板里也有提到，建议先在自己的 fork 的 repo 里完成 CI 之后再提交到 upstream。
这个其实也很简单，我们只要给自己的 repo 提交一个 PR，然后在 repo 设置中开启 Action，之后就会触发 CI 了。
如果自己的 PR 还需要频繁的提交修改，那建议可以先修改为 draft，这样可以提醒维护者稍后再做 Review。
同时也不建议提交一个过大的 PR，尽量控制在 500 行改动以内，这样才方便 Review。
Github 有提供代码对比页面，但也只是简单的代码高亮，没法像 IDE 这样提供函数跳转等功能。
所以对于 Reviewer 来说，最好是在本地 IDE 中添加 PR 的 repo，这样就可以直接切换到 PR 的分支，然后再本地跟代码，也更好调试。
有相关的修改建议可以直接在 github 页面上进行评论，这样两者结合起来 Review，效率会更高。
Review 代码其实不比写代码轻松，所以对免费帮你做 Review 的要多保持一些瑞思拜。
现在 Github 已经支持 copilot 自动 Review 了，它可以帮我们总结变更，同时对一些参加的错误提供修改建议。
使用它还是可以帮我们省不少事情，推荐开启。
在企业内部做 Code Review 流程上要简单许多，毕竟沟通成本要低一些，往往都是达成一致之后才会开始开发，所以重点就是 Review 的过程了。
既然是在公司内部，那就要发挥线下沟通的优势了；当然在开始前还是建议在内部的代码工具里比如说 gitlab 中提交一个 MR，先让参会人员都提前看看大概修改了哪些内容，最好是提前在 gitlab 中评论，带着问题开会讨论。
实际 Review 过程应该尽量关注业务逻辑与设计，而不是代码风格、格式等细枝末节的问题。
提出修改意见的时候也要对事不对人，我见过好几次在 Review 现场吵起来的场景，就是代入了一些主观情绪，被 Review 的觉得自己能力被质疑，从而产生了一些冲突。
Code Review 做得好的话整个团队都会一起进步，对个人来说参与一些优质开源项目的 Code Review 也会学到很多东西。
最近有开发者在整理代码仓库、尝试将代码与数据分离时，借助 `filter-repo` 等工具，引发了关于究竟该用 `git submodule` 还是 `git subtree` 的思考。这篇文章就深入对比了这两个看似功能相似、实则内核与适用场景迥异的 Git 功能。 两者最核心的差异在于代码的“存在形式”。`submodule` 像是一个精确的指针，它只在你的主仓库中记录一个指向特定子仓库提交的链接。因此，主仓库保持精简，但每次克隆或拉取后，你都需要额外执行 `git submodule init` 和 `update` 来同步子模块内容，管理上更为“显式”。 相反，`subtree` 则采用“拿来主义”，它将子仓库的代码内容直接合并到主仓库的指定目录下，代码成为主仓库历史的一部分。你无需额外步骤就能看到并编辑全部代码，操作更直接，但代价是主仓库的历史记录会膨胀，且后续同步上游更新时可能产生更复杂的合并。 这种差异直接决定了它们的适用场景。如果你的子项目是清晰分离、需要独立版本管理且上游更新频繁的组件（例如共享库），`submodule` 提供了干净的隔离。若你只是希望将某个外部项目的某次快照代码嵌入你的项目，或对代码的便捷访问和单一仓库管理的需求高于历史清洁度，那么 `subtree` 的“一体化”方案会更简单省心。文章通过一个真实的代码整理场景，清晰地剖析了这两种方案的优劣与选择依据，能帮助开发者在项目管理和代码组织时做出更合适的决策。
这篇梳理了开源 AI 代理平台 OpenClaw 从 v2026.1.5 开始的完整演进时间线。文章不只是简单罗列版本更新，而是通过关键版本节点，勾勒出项目从“接入模型的机器人”成长为“AI 工作台”的完整轨迹。 作者指出，从 v2026.1.5 开始，项目以“clawdbot”为名稳定发布，随后在 v2026.1.14-1 至 v2026.1.16-2 期间，通过引入网页搜索、浏览器控制、Hooks 等能力，快速具备了 Agent 系统雏形。中间一段因商标压力短暂更名为“Moltbot”的插曲也被记录下来。 最重要的拐点出现在 v2026.1.29，项目正式、全链路地更名为 OpenClaw。此后，经过 v2026.2.1 的系统性收口，到 v2026.3.12 带来 Dashboard v2 与 Provider 插件架构，平台化方向日益清晰。最终，项目在 2026 年 3 月 1 日，其 GitHub Star 数超越 React 成为非聚合类项目之冠，成为影响力出圈的标志性时刻。整篇文章通过时间线与关键变化解读，生动展示了一个项目在品牌、技术与社区三个维度的协同进化过程。
这篇讲的是一位互联网“老兵”对自己所在行业中“70后”技术人踪迹的寻觅与思考。 作者从自己公司春节后只剩一位70后同事的“残酷真相”出发，回溯了在洪恩、用友、锤子等公司的经历，发现自己在不知不觉中成了团队里最年长的人。他调研发现，当年那批使用JDK 1.4、HTML4的第一代程序员，并没有消失，而是悄然分流：一部分晋升为大厂高管（如阿里的逍遥子、鲁肃），一部分在技术领域持续深耕，还有不少人转行、投身区块链、回归故里或消失在创业公司的起起落落中。 文章并未停留在感慨，而是深入剖析了这一现象背后的原因：互联网行业本身年轻，早期从业者本就稀少，而行业的剧烈发展又在不断稀释着这些“老人”的比例。作者联想到村上春树72岁仍笔耕不辍的创作生涯，以此反思技术人的职业生命周期——年龄增长并非必然意味着停滞，持续热爱与产出才是对抗时间的关键。 文章结尾，作者将个人“逆行”般的职业轨迹（年轻时专注技术，四十岁后反而迎来更广阔的人生）与村上春树的“特质”（30岁后找到写作方向并坚持一生）并置，留给读者一个开放的思考：技术人的中年并非终点，而是可以重新定义起点、继续前行的生命阶段。
这篇讲的是一位技术人的“年龄焦虑”与自我和解。作者从自己在用友、锤子科技，到极客邦创业的经历切入，发现自己一路走来，竟从团队里最年轻的变成了最年长的那个——入职极客邦的第一天，就成了公司年龄最大的人。 文章的核心并非抱怨，而是通过这些个人观察与同行趣事，引出了一个更普世的思考：我们是如何看待衰老的？作者坦言，人过四十，所谓的“不惑”更像是接受“有些事再也想不明白”的现实，而午夜梦回时，对青春理想的追问仍会惊出一身冷汗。 但他最终的态度是清醒而积极的。他援引姜文的“不怕老”，提到七十多岁的创作者依然笔耕不辍，并认为当代的技术人，尤其是七零后、八零后，很可能将“精力充沛地工作到七十岁甚至八十岁”。全文用一种混合了自嘲、哲思与幽默的笔调，探讨了成长、边界与梦想的消逝，最终回归到一个朴素的观点：认清年龄的边界，或许才是真正的超越。
这篇讲的是资深工程师在面对琳琅满目的开源项目时，如何做出不后悔的选择。作者从自己曾受邀为校招生做技术分享的背景出发，分享了沉淀下来的三点实用原则。 核心观点非常明确：选项目，本质上是选“人”。具体来说，一要看项目是否活跃，有持续演进的历史，拒绝“已死”的项目；二要看项目主导者是否善于沟通，这是项目能否健康演进的关键；三要看项目是否专注，解决单一问题的“小而美”项目更便于集成与取舍。 作者特别强调，我们不必苛求代码完美，因为选择使用一个开源项目，就意味着选择了与维护者同行。真正重要的是找到那些勤奋、开明且专注的“合作伙伴”。文中还顺带吐槽了国内某些只发代码快照、缺乏持续维护的“伪开源”现象，让这个选择原则显得更加切中时弊。
这篇文章记录了作者从2020年3月开始，持续在家工作一整年的回顾与思考。作者结合2003年SARS的“宅家”经验，原本对疫情持续时间预计乐观，但事实远超预期。文章详细描述了从公司通知可自愿远程办公、自己随后出现流感症状并康复，到逐步搭建起稳定家庭办公环境的全过程。 技术细节上，作者分享了配置居家办公设备时遇到的实际“坑”：例如使用HP USB-C显示器为Pixelbook供电时，发现显示器供电不足，需额外占用USB-C口或使用带供电的Hub；某些设备直接连接显示器无法工作，改用USB-A转C线缆则能解决。这些具体经验对面临类似设备兼容问题的读者有直接参考价值。 生活层面，文章记录了为适应居家状态，在购物（转向农场团购）、车辆维护、个人护理（购置推子自助理发）及家庭清洁（引入扫地机器人）等方面发生的切实变化。此外，作者还提及在加州山火季，如何制定应急撤离清单并检查数字备份，展现了应对突发风险的准备思路。 结尾部分，作者在反思中指出，尽管居家一年完成了不少工作，但疫情无疑打乱了许多计划，也影响了更深远影响力的产生。文章在平静的记述中，流露出对逝去时光的感慨和对行业困境的观察。
作者从一次 Git 仓库迁移实践出发，指出不少人在操作时会遇到问题。文章系统梳理了三种主要的迁移方法，并剖析了其中的门道。 最常见的直接 `git push` 方法，其实只能迁移本地已有的分支引用，远端的其他分支和标签都会丢失。为了解决这个问题，文章介绍了两种更可靠的方案。一种是使用“裸仓库”（`--bare`），它只包含版本库数据而没有工作目录，非常适合用于纯粹的数据中转。另一种是“镜像仓库”（`--mirror`），它比裸仓库更进一步，保持了与源仓库的同步能力，适合需要后续持续更新的场景。 作者最终推荐使用裸仓库的方法进行一次性迁移，因为它操作直接且彻底。对于需要长期保持同步的场景，则可以选择镜像仓库。这篇文章清晰地对比了不同方法的原理与适用情况，能帮助读者根据自身需求选择最合适的迁移路径。
这是一位有七年工作经验的后端开发者的自述。文章以时间线回顾了他从测试开发转至Python后台开发，历经创业公司起伏后在现公司沉淀的历程，并由此分享了对学习、生活与工作的核心思考。 在学习上，作者形成了两个关键观点：一是从实际工作需求出发，进行“学以致用”的实践循环，避免无效投入；二是跳出日常，从职业规划与行业趋势出发，系统性地构建个人的技能树。他反思了过去盲目追求技术热点、购买大量书籍却转化率低的“盲区”，并推荐了以深度和体系化见长的学习资源。 生活方面，作者强调“follow your heart”做出选择并为之负责，同时要警惕注意力陷阱——通过限制屏幕时间、关掉不必要的通知，将更多精力投入到阳光、运动等真实生活的美好细节中。他提出通过仪式感（如“电影之夜”）打破模式化的僵局。 对于工作，他总结了几点心得：多站在对方角度思考、保持谦虚并真正反省改进、凡事“多走一步”，以及最根本的，建立自己专业与靠谱的口碑。 文章结尾处，作者坦言过往种种皆为积累，未来仍需不断学习与成长，并计划重新拾起笔记录思考。这七年的折腾与沉淀，最终指向一个清醒的认识：规划与持续行动是成长的关键。
这篇讲的是Git分支合并的“四重奏”。作者从“在Git里改变历史是可能的”这个有趣的比喻切入，把抽象的版本控制操作讲得像在不同宇宙间穿梭。 文章图解了四种核心合并方法：最常用的merge其实有三种模式——fast-forward在无分叉时直接移动指针，效率最高；`--no-ff`会强制保留合并节点，让历史更清晰；`squash`则把多个提交压成一个，适合整理功能分支。除此之外，还介绍了rebase，它通过重写提交历史来创造线性、干净的版本树；以及灵活的cherry-pick，可以像摘樱桃一样精确选择某个提交合入当前分支。 作者通过动态示意图，清晰展示了每种操作对提交历史树的影响，比如rebase会将原本分叉的提交“移植”成直线。这种可视化对比，能帮助开发者快速理解不同策略的差异：merge适合保留完整上下文，rebase擅长维护主线整洁，而cherry-pick在修复特定问题时无往不利。 掌握这些方法的区别，就像拿到了Git历史管理的完整工具箱，面对再复杂的分支拓扑也能从容应对。
对于刚开始接触 Linux 和版本控制的开发者来说，如何将本地代码可靠地同步到云端协作平台，往往是迈向开源世界的第一道坎。这篇文章就为 Ubuntu 用户提供了一份清晰、可操作的入门路线图。 它没有停留在抽象概念，而是直接从终端命令开始，手把手演示了在 Ubuntu 系统上完成 Git 安装、GitHub 账户配置、创建本地仓库、添加文件、提交更改，直至最终将整个项目推送到 GitHub 远程仓库的全过程。文章特别强调了几个关键步骤的实际操作：例如使用 `sudo apt-get install git` 进行安装，通过 `git config` 命令绑定你的用户名与邮箱，以及用 `git add` 和 `git commit` 来管理文件变更。这些步骤都配有具体的命令示例和效果截图，让读者能逐一对照执行。 整篇指南面向已注册 GitHub 账号、但对 Git 工作流尚不熟悉的 Linux 初学者。它省略了复杂的理论铺陈，聚焦于“如何让它跑起来”，非常适合想要立刻动手实践、将自己的第一个小项目托管到 GitHub 上的新手开发者。
这篇年度盘点里，作者分享了2016年在家庭、工作和生活上的多重变化与思考。技术篇幅主要围绕一次漫长而曲折的前端重构：最初目标只是将大型CSS文件变量化，却在过程中发现选择器与逻辑混乱，最终演变为前后端代码的全面重写。文章详细描述了项目如何因过度设计、人员变动和实际复杂度而一度失控，又如何在下半年通过聚焦功能完成、样式适配与浏览器兼容，最终在年末成功上线。 在工作层面，除了代码实践，作者也坦诚地谈到团队管理上的学习——认识到只注重过程不够，结果才是关键，同时也需要提升沟通技巧。生活方面，记录了新房装修、孩子莫莫出生带来的重心转移，以及由此引发的消费观念转变：败家重心从个人数码产品（如为家人购置红米手机、小米空净）转向家庭开支与育儿投入。 整体而言，这不仅是一份技术项目的复盘，更像是一位开发者对工作与生活平衡的观察。作者在结尾反思了理财与买房决策，流露出对“结果导向”与“人生自主”的朴素理解，让技术人的年度总结多了几分生活温度。
这篇讲的是，作者从网络上常见的观点论战现象出发，提出一个鲜明主张：别在与你观点不同的人身上浪费时间。但这里的“不浪费”，核心意思是，把心力和专注点都放在做成事情、拿出结果上。 文章首先点出，面对不同观点，关键在于理解其背后逻辑——对方为什么这么想、推论有何盲点。如果这过程能启发你，那就“闷声发大财”；如果明显有问题，在没有特别义务时，保持沉默对双方都好。作者以自身文章较少引发撕扯为例，说明看透逻辑能平息辩解冲动。 更深一层，作者强调价值观差异不可调和。像“求同存异”一样，在不得不合作时找共同点，但根本信念不同的人，比如信奉投机取巧与勤劳扎实者，在关键时刻反应迥异。对此，既不必说服，也费劲无效，各自相安为上策。 归根结底，观点分歧在成年人世界里并不重要，重要的是你能否依托自己的价值体系持续进步，做出成果。作者举华为为例——即便被诟病加班文化，但年业绩800亿美元的实绩无可辩驳；而对比一些连房租都愁却网络论政的人，文章建议先“修好自己的身”。 最终，作者回到开头：不争论，是为了专注成长与产出。当你内心不认可他人时，要意识到，你对他而言也一样不重要。所以，大家都去好好干活吧，干出来的成果，往往自有相似的力量。
这篇讲的是如何在CentOS服务器上从零搭建一套功能完备的Git代码托管环境。作者面对的核心需求是建立一个集中式的版本库，用于团队协作和代码管理，同时希望方案对服务器性能的影响尽可能小。 文章给出的解决方案是一套组合拳：使用Git作为底层版本控制工具，并搭配gitosis和gitweb两个组件。其中，gitosis专门负责基于SSH协议的仓库权限管理，而gitweb则提供了一个简单的Web界面，方便开发者在线浏览代码和提交历史。文章以“折腾”的口吻，依次拆解了这三个部分的安装与配置过程，从yum安装基础软件包、创建git用户，到克隆gitosis源码进行安装、配置SSH密钥实现安全访问，最后安装fcgiwrap与spawn-fcgi来驱动gitweb。 整个流程清晰且具有可操作性，比如在配置客户端多公钥共存时，就给出了具体的.ssh/config文件示例。最终搭建完成的服务器既能通过SSH进行高效的代码推送与拉取，也能通过网页轻松查看项目状态，是一个轻量且实用的自托管方案。
这篇讲的是一位前阿里员工从自身职业经历出发，给正在考虑裸辞的技术人提供务实建议。 作者校招进入阿里做Java Web，因对Android开发产生兴趣，在职自学一年后选择裸辞，转型成为Android开发者。他详细复盘了当时的决策过程：一方面因为内部平台成就感低，另一方面确实需要整块时间学习和开发App。裸辞后他休息了两个月，骑行川藏线，之后加入了Android ROM创业公司。 不过，文章的重点在于后续的反思与建议。作者明确表示“不建议裸辞”，并深入剖析了核心原因：裸辞后作为失业者，求职和谈薪都会处于被动，尤其对于转技术方向的人，技能不熟练会成为明显短板；同时，持续的消费和收入中断会带来切实的生活压力。相比之下，他强烈建议“内部转岗”。BAT等大公司内部通常有不错的技术资源和转岗机制，这既能让你切换到感兴趣的领域，又能规避裸辞带来的职业空窗期风险。 文章最后提醒，技术学习终究要靠自己，不必过度追求“共同进步”的环境。对于“打杂”期感到不满的新人，他建议先理清自身目标与能力，对自己的职业规划负责。这是一篇带着过来人温度与理性计算的职业规划指南。
