Mercurial 提交与实际生产图答案

【问题标题】：Mercurial Commits vs Actual Production GraphMercurial 提交与实际生产图
【发布时间】：2011-09-21 03:33:42
【问题描述】：

好的，我还没有看到这个弹出窗口是关于 mercurial 的综合问题，但这是我最近注意到的。

在查看用于开发软件的其他存储库时，提交非常“理想”，因此如果目标是修复函数 f()，那么提交只是“通过 --- 修复 f()”。我的事，我怀疑每次更正都发生在一次提交中。

我会有类似的东西

[1:尝试 x 修复 f] -> [2:尝试 y 修复 f] -> [3:尝试 z 修复 f] -> [4:f 修复]

我注意到有或没有命名分支，如果我尝试将 [4:fixed] 合并到我拥有的“稳定”分支，那么无论是推动还是拉动更改，它都会拉动 [1:4] 而不仅仅是 [4 ].

我只想将干净的更正推送到存储库或生产设置。共享所有非测试更改的最简单方法是什么？

【问题讨论】：

只是好奇如果它不是修复，你为什么要提交？
每次提交都是开发中的“修复”，但它们是为生产做出更大“修复”所需的较小修复。这是“经常提交”的座右铭。我还在开发中处理许多不同的组件，所以很高兴能检查所有内容。我发现我的答案是在线“暂存变更集”。因此，如果我对更改进行分阶段，而不是获得 50 个次要修订，他们将获得一个包含修复所需的所有次要修订的大规模修订...

【解决方案1】：

rebase extension 和 --collapse。

【讨论】：

【解决方案2】：

如果您只想推送一个干净的变更集，请只制作一个干净的变更集。将多个本地变更集折叠为 1（a la Amber 的回答）是一种方法。

我更喜欢的方式是使用 Mercurial Queues 并在补丁中完成我的一些工作。然后当它完成时，我完成补丁并成为一个变更集。

【讨论】：

我找到了一种方法，可以将更改分阶段到现在不同级别的生产中，这样随着开发的推进，只有“已批准的功能”会出现在生产中。我考虑过 Mercurial Queues，但我似乎无法理解它......