为什么我更喜欢主干开发

最近这里的每一期都有代理人，包括Foojay的，我想休息一个月。所以这次的焦点不是八月的。是的特里莎·吉的“我为什么更喜欢基于trunk的开发”，写道2023年5月在她自己的博客上以及转载于Foojay那个六月。

Trisha 是 Gradle 的 Java 冠军和开发倡导者。她还曾与 Dave Farley 一起工作，当时他和 Jez Humble 正在编写《Continuous Delivery》，据她自己说，正是在那里她见证了基于中继开发的成果。

感谢阅读JVM Weekly！免费订阅以获取新文章并支持我的工作。

下面的文字是她的，未改动，完整放在这里，因为我问她答应了。三年过去了，内容都不需要更新。八月的重点内容紧随其后。

为什么我更喜欢基于中干的开发

最初发表于 Foojay特里莎·吉

如今，像Git这样的分布式版本控制系统已经“赢得了”版本控制的战争。当DVCS逐渐流行时，我常听到的一个论点是，分支和合并VCS比如Git有多容易。

不过，我非常喜欢基于主干的开发（TBD），我想告诉你原因。

在基于trunk的开发中，所有开发者都只在一个分支（例如“main”）上工作。你可能读过或听说过马丁·福勒或戴夫·法利谈论它。正是在我和Dave合作的时候（大约在Git迅速成为“首选”版本控制系统的时候），我真正看到了基于trunk开发对团队的好处，尤其是在一个开创持续交付的环境中——Dave和Jez Humble一起写书，而我则和他一起工作。

相比之下，分支模型鼓励开发者为每个功能、漏洞修复或增强创建独立分支。虽然分支看似隔离变更和降低风险的合理方法，但有几个因素让我对基于trunk的开发更为舒适。

1. 速度与效率

在基于trunk的开发中，整个团队都专注于一个分支。这种模型允许更快的集成和更少的合并冲突。这实际上就是”持续集成（CI）“，这是极限编程实践最初所建议的。虽然如今我们说CI时通常指的是”每次提交时都要在团队服务器上运行你的构建和测试“，但CI真正的意思是定期集成你的代码。存在于不同分支上的代码，按定义，并不是集成的。而这些分支存在的时间越长，将它们合并回主代码库就越困难。在一个不受其他开发者更改影响的独立分支上开发修复和改进看起来可能很快，但你迟早得付出代价。定期将小改动集成到代码中，通常比在较长时间结束后进行大规模合并更轻松。

2. 更高的代码稳定性

基于trunk的开发鼓励频繁提交，从而带来更小且易于管理的变更。为什么以及如何？原因和我们不希望长期分支发生大规模合并一样——提交时间越长，提交与他人更改冲突的可能性就越大。

通过频繁拉入其他开发者的修改，并频繁推送小的可用代码变更，我们知道代码库是稳定且正常工作的。当然，如果有一个CI服务器运行每个提交的构建和测试，这种“稳定且正常”的假设更容易验证。

如果构建出现故障，我们也必须停止提交，专注于修复该构建。在构建已经坏掉的情况下，持续推送小而频繁的提交对任何人都没有好处。

在分支模式下，大规模且不频繁的合并会引入难以识别和解决的错误，因为变更规模庞大。你有没有在别人合并了自己的大项目后，发现你的代码不再正常工作后，把主干合并到你的分支里？

当你做了大量修改，而别人做了大量不同或重叠的更改时，追踪测试失败或应用不按预期工作可能需要非常长时间。这还是假设你有可靠的测试覆盖，能告诉你问题所在。

3. 增强团队协作

我最喜欢的团队成员间知识交流方式是结对编程。我知道不是每个人都喜欢，或者有条件这么做（尤其是现在更多人远程工作，但如果是这样，可以去看看JetBrains的代码).如果你们不配对，至少你们想做同一个代码，对吧？

如果你们都在做自己的分支，那你们就不是在协作。你们是在竞争。看谁能最快完成代码。避免被别人的代码变更踩在脚下。

如果你们都在同一个分支工作，通常会更清楚正在进行的变更。这种方法促进了团队更强的协作和知识共享。相比之下，分支工作可能造成各自独立的工作环境，导致团队内部出现知识差距。

4. 改进持续集成与交付（CI/CD）实践

戴夫·法利的书，持续交付他的日志帖子和视频中，主张类似“基于主干的开发本质上与持续集成和持续交付（CI/CD）实践兼容”。

在基于trunk的模型中，持续集成更简单，因为你的代码经常提交到trunk，而CI环境就是在该分支上运行构建和测试。任何故障都会被及时发现并处理，降低严重故障的风险。

通常很容易追踪导致问题的变更。如果问题无法立即修复，你可以支持导致它的具体变更。

到现在为止，我们应该明白快速反馈循环的重要性——当你更快发现问题时，就能更快找到原因，也能更快地修复它。这会提升软件的质量。

持续交付在基于主干的开发环境中同样蓬勃发展。成功的持续交付依赖于拥有始终处于可部署状态的代码库。基于主干的开发方法通过促进频繁提交、频繁集成和对所有这些集成进行测试来确保这一点。

同时引入的少量变更使软件更容易部署和测试。

相比之下，实施有效的CI/CD时，分支模型可能更复杂且耗时。虽然很容易想“我是在分支上运行构建和所有测试”，但你实际上并非每次提交都集成。

真正整合问题是在合并（或重基）时才开始出现。你在分支“CI”上运行的所有测试根本没有测试任何集成。

合并和测试不同分支代码可能会带来延迟和潜在错误，这会削弱构建流水线带来的一些好处。

5. 减少技术债务

长期存在的分支往往会导致“合并地狱”，即一个分支（比如“主”）与另一个分支（例如你的功能分支）之间的差异太大，导致合并变成一场噩梦。

这可能导致技术债务，因为你可能会诉诸快速解决方案来解决合并冲突，或者接受IDE提出的解决方案，但你并不完全理解这些建议。在基于trunk的开发中，频繁的合并和较小的修改使管理和减少技术债务的积累变得更容易。

总结

我个人认为基于trunk的开发有明显优势，我也亲身经历过在采用这种方法的团队中工作。然而，这需要开发团队内部的心态和文化。你需要经常将其他开发者的修改合并到自己的代码中。

你需要频繁提交小幅修改，这需要你只修改代码的一小部分并做渐进式修改，这往往是一个难以习惯的习惯。双人编程、全面的自动化测试，以及代码审查，是帮助整个团队采用相同方法和文化的关键实践。

基于主干的开发，以有纪律的方式进行，简化开发流程，增强团队协作，提高代码稳定性，支持高效的CI/CD实践，并可能减少技术债务。

虽然如果你一直采用分支模式，适应这种方法可能有挑战，但长期来看其益处是值得的。如果你想转向这种方式，也可以阅读Dave关于基于主干开发障碍的文章.

现在......本月Foojay的其他精彩片段！

小型应用中的脚本：宏不需要容器

奥斯汀·莱曼Aussom的高级集成开发者兼维护者，他在开头透露，接手了JDK留下的线程。JEP 486禁用了JDK 24中的安全管理器，此后所有关于安全运行用户脚本的文章都假设是一个多租户云平台，背后有安全团队支持。

他的观点是，对于桌面应用或内部工具，限制从来不是威胁模型，而是分发：你不能要求用户安装Docker来运行宏，第二个进程或GraalVM隔离程序意味着你拥有启动时间和构建步骤。

所以他颠倒了通常的嵌入故事。与其用一个通用引擎试图限制它，不如用一个足够小的解释器来端到端读取，Java 访问从空的允许列表开始，java.lang.ProcessBuilder除非你输入，否则在解析时会被拒绝。

他给出的数字（创建引擎需要2.6毫秒，空闲时间0.37MB，毫秒内可取消任何线程）来自产品维护者，所以可以当作供应商数据来理解。没有数字，下面的观察依然成立：用户遇到的失败是一个无限循环的宏，冻结了界面，没人注意到沙盒在运行。

在GraalVM原生镜像中运行DuckDB的JDBC驱动

盖尔蒂安·维伦加，Java 冠军兼阿姆斯特丹 JUG 的领导者，回答了一个自 2025 年 3 月以来一直悬于 duckdb-java 第180期的问题，当时维护者曾表示提前编译不太可能与驱动兼容。

它至今仍然运行，驱动没有任何更改，有趣的是它曾经失败的原因。DuckDBNative有一个静态初始化器，可以提取本地库并调用System.load并且有绝对路径。

GraalVM for JDK 17 在构建时运行了类似的初始化器，所以从构建机的路径被冻结到二进制文件中，其他机器则UnsatisfiedLinkError.由于 GraalVM 在 JDK 22 应用类中会在运行时初始化，除非构建能证明初始化器无副作用，而提取文件是副作用，因此默认更改后该漏洞消失了。

兼容性问题是双向的：GraalVM for JDK 22 于 2024 年 3 月发布，比问题开放早一年，直到现在才有人重新运行该构建并发布结果。实际数据：二进制约为 120 MB，其中 108 MB 是 DuckDB 引擎，由于每次连接打开驱动都会将该库解压到临时目录，他的实际对账工具原生运行速度为 0.95 秒，而 JVM 为 1.36 秒。

39 毫秒--help时间是真实的，它并不能告诉你一次能打开连接的游戏。

Azul 2026年8月发布：Java首次月度CSPU

弗兰克·德尔波特这次，作为Azul的高级技术写手，参与了首个月度关键安全补丁更新：第188卷的第四位数字，从发行商角度展示。标题低估了两个细节。

“每月”是CSPU最常发布的日期。季度更新之间的第三个星期二是为CSPU保留，如果OpenJDK社区认为修复需要修复，且正如Frank指出，目前还没人确认九月发布，所以等待日期的流水线等待时会错。

显然对每月补丁的反对意见是测试窗口缩小，解决方法是将每个 CSPU 拆分为两条线：一个只在最后一个季度 CPU 上安装安全修复的 CPU 构建，另一个是将累积的非安全修复添加在上面的电源构建。

Azul 推荐生产线的 CPU 系列，因为它变化最小。但问题是，只有 PSU 系列对免费的 Zulu 社区用户开放，所以没有支持合同的用户会获得更大的差异。

8 月版本修复了五个 CVE，其中四个适用于 Zulu，2D 版本为 7.5。

就这些，朋友们。

感谢阅读JVM Weekly！

感谢阅读JVM Weekly！免费订阅以获取新文章并支持我的工作。