2

我正在尝试掌握 Mercurial 的基础知识，所以请多多包涵。:) 我目前的工作流程如下：

  • 做一些工作，直到我准备好提交或需要其他人的更改
  • 拉
  • 在这一点上，我想将我的工作与最新的变更集合并并提交，但是 Mercurial 坚持让我在合并之前提交
  • 所以它就像“提交，合并，提交”，我基本上提交了两次，在两个变更集中编写相同的注释并一次推送两个变更集

是这样的吗？每次合并是否可能只有一个变更集来自我？真的可取吗？

我已经阅读了很多在线手册，但仍然觉得我对这个过程没有深入的了解。欢迎所有评论。谢谢！

编辑：原来我不知道更新可以将传入的更改与未提交的编辑合并。

4

3 回答 3

3

合并总是在 Mercurial 中创建一个单独的变更集。

另外，只要您在本地存储库中有未提交的内容，就不可能进行合并。
所以解决方案是先commit，然后再pull和merge。
这将始终导致两个变更集，而不是一个。
（...因为合并总是创建一个单独的变更集）

但是你不会两次提交相同的东西，尤其是你不应该两次写相同的提交信息：

第一次提交是您实际更改的内容（“修复了 foo bar 中的错误”）。
第二次提交只是合并（TortoiseHG 实际上用“Merge”预先填充了提交消息，99% 的时间我只是这样离开它）。

于 2012-08-28T20:55:08.887 回答
2

此工作流程将阻止历史记录中的合并，但您仍会执行如下所述的合并：

  • 做一些工作，直到您准备好提交或需要其他人的更改。
  • hg pull
  • hg update（注意：hg pull -u在一个步骤中执行此操作和上一个操作。

在 期间hg update，您未提交的更改将与当前分支的新提示合并。您仍然需要解决任何冲突。

  • hg commit准备好时。

我仍然建议您是否在拉/合并之前先提交大量更改，因为如果合并不顺利，通过更新到该更改集来重新开始会更容易。

保持hg pull和hg update分开允许您查看传入的变更集并预测合并将如何进行。

于 2012-08-29T01:20:50.770 回答
1

感觉奇怪的原因是您延迟提交，直到您想与其他人集成。

分布式版本控制的一大特点是提交是本地的。因为它们是本地的，所以你应该经常提交——每次你完成一小部分一致的工作时提交。您的提交不会立即施加于其他人，因此您不会通过进行许多小提交来打断他们。

如果您开始进行更多提交，您将看到您的工作流程变为：

$ hg commit -m "Refactoring for Issue123"
$ hg commit -m "Basic functionality for Issue123"
$ hg commit -m "Fixed off-by-one error (Issue123)"
$ hg commit -m "Finished implementing Issue123"
$ hg commit -m "Added more tests for Issue123"
$ hg commit -m "Begin use new function from Issue123"
$ hg pull
$ hg merge
$ hg commit -m "Merge"

在这里，合并提交与“真实”提交的比率要合理得多。

许多人（包括我自己）喜欢使用rebase 扩展来完全避免合并。该扩展通过伪造历史来线性化提交，这样看起来就像您在使用hg pull. 工作流程中唯一的变化是您hg rebase而不是hg merge上面然后跳过最终提交。

于 2012-08-29T08:32:10.257 回答