当变更集较小时，Mercurial 是否能更好地合并文件？
假设我有一个名为“myDevelopmentBranch”的功能的开发分支，另一个分支“myOtherBranch”包含相当多的更改，其中一些会与“myDevelopmentBranch”中的内容冲突。如果我频繁提交，从“myDevelopmentBranch”到“myOtherBranch”的合并结果是否（可能）会有所不同，如果我提交的频率较低（例如，每天几次与每周一两次）？我想知道这一点，因为我认为 Mercurial（或任何其他 VCS）更容易跟踪小块的更改，因此可以更好地弄清楚如何合并它们。
笔记！我知道为什么一个人应该频繁提交的原因有很多，这只是我一直在思考的一个技术问题。
Let's say I have a development branch for some feature called "myDevelopmentBranch" and another branch "myOtherBranch" containing quite a lot of changes, some of will conflict with stuff from "myDevelopmentBranch". Will (potentially) the result of a merge from "myDevelopmentBranch" to "myOtherBranch" be different if I commit frequently than if I commit less often (e.g. several times a day versus one or two times per week)? I'm wondering about this as I would thing that it's easier for Mercurial (or any other VCS) to track changes in small chunks, hence doing a better job figuring out how to merge them.
Note! I'm aware of plenty of reasons to why one should commit frequently, this is just a technical question that I've been pondering about.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
合并解决了已更改文件之间的差异，因为它们位于两个分支的尖端（假设您正在合并尖端）。因此，如果您...
...与 50 个变更集相比，您将获得相同的合并体验每个分支各更改 10 行，以在每个分支中生成与上述相同的文件最终状态。
然而，根据我的经验，使合并变得更容易的不是经常提交，而是经常合并。例如，将稳定分支的更改合并到开发分支中，以使开发分支保持在较小规模的最新稳定版本的基础上，而不是等到开发分支上的工作完成后才用大的稳定分支更改来更新它咬。在某些情况下，稳定分支的变基会发生变化而不是合并（取决于您的 DVCS 工作流程）。
The merge resolves differences between the changed files as they stand at the tip of both branches (assuming you are merging the tips). So if you had...
...you would have the same merge experience compared with 50 changesets on each branch that change 10 lines each to produce the same final state of files in each branch as above.
However, in my experience what does make merging easier is not committing often but merging often. For example, merging changes of a stable branch into a development branch to keep the development branch based on the most recent stable version in smaller bites, rather than waiting until work on the development branch is done to update it with stable branch changes in one big bite. And in some cases, rebasing the stable branches changes instead of merging (depending on your DVCS workflow).