blocks|key|1804943|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1804944|不过，在处理可解决的冲突方面，Git可能比SVN更好。它的主要合并策略是递归的，即找到更改同一文件的两个提交的共同祖先，并执行三向合并。它还具有一些内置功能，用于记录和重用冲突解决方案(git-rerere)以及用于特殊情况的各种其他merge+strategies。|offset|length|1804945|Git的历史模型(有向无环图)预计会有这样的提交。一直都是。(是的，有时会有冲突，但它们是真正的冲突，而不是无法处理合并。)|1804946|另一方面，SVN只是尝试跟踪合并发生的位置，但其模型本质上仍然是线性的。历史记录仍然只有一个提交字符串，合并跟踪信息提供了额外的帮助。据我所知，SVN并不总是能正确处理更复杂的合并模式。(一个示例是反射合并-将A合并到B中，然后将B合并到A中。)|1804947|entityMap|0|LINK|mutability|MUTABLE|url|http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html|1|http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_merge_strategies^0|0|2L|A|0|39|G|1|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|5|6|T|7|@]|8|@$C|U|D|V|1|W]|$C|X|D|Y|1|Z]]|9|$]]|$1|E|3|F|4|5|6|10|7|@]|8|@]|9|$]]|$1|G|3|H|4|5|6|11|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|12|7|@]|8|@]|9|$]]]|J|$K|$4|L|M|N|9|$O|P]]|Q|$4|L|M|N|9|$O|R]]]]

The specific conflict you mention is always unresolvable. There's simply no way for a merge tool to know which version should be kept.

Git is probably better than SVN at dealing with resolvable conflicts, though. Its primary merge strategy is recursive, which finds the common ancestor of two commits changing the same file and does a three-way merge. It also has some built-in capability for recording and reusing conflict resolutions (<a href="http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html" rel="noreferrer">git-rerere</a>) and a variety of other <a href="http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_merge_strategies" rel="noreferrer">merge strategies</a> for special cases.

Git's advantage in merging is that it's part of the history. A merge commit is a commit with two parents. Git's model of history (a directed acyclic graph) expects there to be commits like this. This means that further merges in the future work exactly how they should. Always. (Yes, there are sometimes conflicts, but they're real conflicts, not an inability to handle the merge.)

SVN, on the other hand, just tries to track where merges occurred, but its model is still inherently linear. The history still just has a single string of commits, with merge tracking information providing extra help. From what I've heard, SVN can't always handle more complex merge patterns correctly. (One example is a reflective merge - merging A into B then B into A.)

As the title suggests, I am curious as to why so many people tout Git as a superior alternative to branching/merging over SVN. I am primarily curious because SVN merging sucks and I would like an alternative solution.

How does Git handle merging better? How does it work?

For example, in SVN, if I have the following line:

Hello World!

Then user1 changes it to:

Hello World!1

then user2 changes it to:

Hello World!12

Then user2 commits, then user1 commits, SVN would give you a conflict. Can Git resolve something simple as this?

What's the difference between SVN and Git for merging?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

正如标题所暗示的那样，我很好奇为什么有这么多人吹捧Git是比SVN分支/合并更好的选择。我之所以好奇，主要是因为SVN合并很糟糕，我想要一个替代的解决方案。Git如何更好地处理合并？它怎麽工作?例如，在SVN中，如果我有以下行：你好，世界！然后user1将其更改为：Hello World!1然后user2将其更改为：H...

SVN和Git在合并方面有什么不同？-腾讯云开发者社区-腾讯云

问SVN和Git在合并方面有什么不同？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN和Git在合并方面有什么不同？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN和Git在合并方面有什么不同？
EN