Kode Vicious - @kode_vicious
PDF尽早合并，频繁合并
整合分支开发中的变更
亲爱的 KV，
在进行合并开发时，应该多久合并一次？ 显然，如果我等待太久，我就会陷入合并地狱，在那里一切似乎都不起作用，而且我最终使用回滚命令比提交更频繁；但是分支开发的重点是能够保护主开发分支免受不稳定变更的影响。 是否存在一个折衷方案？
合并守护进程
亲爱的 Merge，
多年来，人们一直在问我关于“折衷方案”的问题，不仅在分支开发中，而且在许多领域也是如此。 我不知道你是否注意到这一点，但这些问题的基调很少是快乐的，甚至更少能产生任何可以被认为是折衷方案的结果。
在处理合并炼狱（如果是地狱，那就没有逃脱的机会，但从炼狱中，你或许可以努力走出来）时，有两个相关的主题。 第一个主题与你正在开发的软件的开发方式有关。 如果代码的各个部分之间有明确的界限，那么你真的不应该进入合并炼狱，因为如果你正在开发一个组件，那么就不应该有其他人对它进行更改； 唯一的差异将是你自己的，事情就结束了——而且做得很好。 当然，在任何大于几个人的项目中，这都是不太可能的。
项目通常存在每个人都插手所有代码的问题。 如果项目规模很小，这并不难解决：你可以简单地与其他项目参与者坐下来，沿着一些逻辑边界划分工作。 在一个大型项目中，你很可能有多个人查看和修改同一段代码。 也许一个人在修复错误，而另一个人在开发新功能，或者产品或项目有两个版本，不同的团队从同一主线工作。 无论如何，你应该做一些事情来避免炼狱——例如拥有一个自动化构建过程，以便每个人都知道何时有损坏的东西被合并或签入。 有关此内容的更多信息，请参阅我在“Broken Builds”（即将发表在 Communications of the ，2009 年 12 月）中对 Made to be Broken 的回复。
第二个也是与本次讨论更相关的重点是合并的方向。 当你在自己的分支中工作时，这有点像在一个建筑物的角落里工作——通常是一个安静的地方，远离同事的喧嚣，在那里你可以专注于你的工作并完成工作。 可惜的是，当你在这种临时的涅槃中编码时，世界其余地方仍在继续，伴随着所有的痛苦。 如果你可以留在涅槃中就好了，但是，好吧，你不能。
你有两种选择：你可以决定尽可能长时间地留在涅槃中，然后在最后大步走进合并炼狱的入口，或者你可以允许少量的痛苦进入你的世界。 在这种情况下，痛苦是来自主分支的合并，每个人都在其中提交更改，而你所有的痛苦最终都来自那里。 当我进行分支开发时——在这一点上，这大约占 95% 的时间——我尽早合并并且频繁合并，就像我投票时一样。
现在，当我说“尽早合并”时，我并不是指“早晨”。 事实上，我几乎从不说“早晨”，因为我真的不相信存在这样的时间，任何试图告诉我存在这样时间的人，我都认为是我想象中的人物。 特别是，我建议在你编写或调试一些自己的代码之前，不要合并任何其他人的代码。 没有什么比在你开始工作日时，别人的损坏代码搞砸你美丽的分支更令人沮丧的了。 先完成一些你想做的事情，然后将主分支的一些痛苦整合到你自己的分支中。 我更喜欢在我感觉自己完成了一些工作后进行这些类型的合并。 至少这样我就以高昂的情绪开始，而修复我的分支的苦差事会将我带回到中立状态，而不是让我陷入代码抑郁症。 我会说，在一个快速发展的项目中，你应该每天从主分支合并一次，并且至少每周一次。 一周内会发生很多事情，你不希望把你的周末花在修复你的工作分支上。
何时最好将代码合并回主干？ 这取决于你要合并什么。 如果是错误修复，那么它们需要在测试后尽快合并，因为可能还有其他人依赖这些错误修复。 对于功能，它们应该是完整的，这意味着经过测试并可以使用。 完整 并不意味着 没有错误。 在某个时候，你必须停止打磨那块粪土，然后把它冲进系统。
这涵盖了何时合并的流程部分，但也有一个工具组件。 有些源代码控制系统根本没有支持分支开发的工具，而另一些系统则鼓励如此多的分支，以至于代码永远不会回到主线。 如果你想进行分支开发，请避免这两种类型的系统。
一个好的分支开发系统必须包含一个用于比较文件多个版本的体面工具。 在一个更美好的世界里，源代码控制系统有可能自动处理所有合并，但这目前尚不可能，因此执行合并的行为实际上是处理合并过程中的异常。
如果计算不同分支中文件之间差异的工具很差，那么将需要你进行更多的工作来整合差异。 人们称之为“合并地狱”的原因不是因为合并本身，而是因为需要大量的人工干预。 你是否希望将 Bob 编写的 1.2.2.1 版本中的代码与你当前版本中的代码合并？ 这些是使合并如此令人不快的决定类型。 从积极的方面来看，这是一个已知的问题，许多人正在非常努力地为我们提供更好的工具，因此这是一个事情实际上正在改善的领域。
总而言之，我的建议是每天将更改整合到你的分支中——但不要在一天开始时——并使用一个现代化的源代码控制系统，该系统对合并更改和解决差异有良好的支持。
KV
喜欢它，讨厌它？ 让我们知道
KODE VICIOUS，凡人称之为 George V. Neville-Neil，以网络和操作系统代码为乐和获利。 他还教授各种与编程相关的课程。 他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。 他在马萨诸塞州波士顿的东北大学获得计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。 他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。
© 2009 1542-7730/09/1000 $10.00
最初发表于 Queue vol. 7, no. 9—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中受到越来越多的关注。 直观地看，技术领导者普遍接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，研究生产力方面的差异，从而为该主题提供新的见解。 低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。 在其快速前进的步伐中，它容易受到时尚的摆布，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。 用例，最初于 1986 年引入并在后来普及，就是这些成熟的解决方案之一。
© 保留所有权利。