有利于更多合并的 VCS 是什么，或者最小化合并问题的最佳实践是什么？
在我们工作的地方，我们遇到了很多合并问题。我们使用 SVN，我知道这不是工具的问题，而是策略的问题。但是，可以最大程度地减少这种情况的最佳合并实践/政策是什么。或者是否存在比 SVN 更容易合并的 VCS？
here where we work, we have a bunch of merging problems. We use SVN and I know that is not a problem with the tool, but with the policy. But, what are the best merging practices/policies to minimize this. Or is there a VCS that makes merging more easier than SVN?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
没有任何工具可以在所有情况下自动合并。自动合并的结果始终是最佳猜测。您有机会在提交之前验证合并结果。
一般来说，SCM 存在许多模式和陷阱。这个网站是一个非常好的信息来源：www.cmcrossroads.com< /a>
您可能提到的反模式被分类为 MergeMania 。
There is no tool that will merge automatically in all cases. The result of an automatic merge is always a best guess. You have a chance to verify the merge result before comitting.
There are a bunch of patterns and pitfalls that come with SCM in general. A really good source of information is this site: www.cmcrossroads.com
The anti-pattern you might be referring to is categorized as MergeMania.
我附议上面的问题：“一堆合并问题”具体指的是什么？
无论如何，我的经验是分布式版本控制系统（DVCS）——例如 Mercurial、Git——在合并方面比 Subversion 聪明得多。尽管许多受 svn 约束的开发人员由于合并的痛苦而避免分支，但在 DVCS 中，它是工作流程的常规且轻松的部分。
（您可能没有能力让您的工作场所切换系统，但无论如何都要学习 DVCS。它会让您成为更好、更有市场的开发人员，甚至可能提供解决您当前问题所需的灵感。）
I second the question above: what specifically does "a bunch of merging problems" refer to?
In any case, my experience is that distributed version control systems (DVCS) -- e.g. Mercurial, Git -- are a lot smarter about merging than Subversion. Whereas a lot of svn-bound developers avoid branching because of the pain of merging, in DVCS it's a regular -- and painless -- part of the workflow.
(You may not have the power to get your workplace to switch systems, but learn a DVCS anyway. It'll make you a better and more marketable developer, and it might even provide the inspiration needed to solve your current problem.)