Git中的合并冲突与Subversion中的合并冲突相比如何？

当我在Subversion中工作时，我总是在

svn提交之前执行
svn更新
。如果有任何冲突，我在更新时会收到警告。然后，在我的工作目录中，我得到
filename.java
，
filename.java.mine
，
filename.java.r10
，和
filename.java.r13
。根据这些文件，我找出了如何解决冲突，将其标记为已解决，然后提交

我对Git还比较陌生，所以我试图弄清楚上面的工作流程对Git来说是什么。哪些git命令可能导致合并冲突？在我的工作目录中是否会出现与上述文件等价的文件？
有许多可能导致合并冲突的
git
子命令，包括
merge
（和
pull
，因为它本质上是
fetch
，然后是
merge
），
cherry pick
，
rebase
等<但是，code>git

以一种根本不同的方式处理合并冲突。它不是为不同版本创建单独的文件，而是创建一个单独的文件，其中的部分用分隔符标记，以指示它们来自三方合并等式的哪一部分。因此，您可以编辑一个冲突的文件，或者删除您不想要的部分和分隔符，或者如果双方都不完全正确，则使用适当的手动合并混合文件替换它，然后

git add

和

git commit

。分隔符是由7个

字符组成的序列（如果您配置了

diff3

格式，则有时是

|

），看起来如下所示：

<<<<<<<
stuff from your version of the file
|||||||
stuff from the common ancestor of the two
=======
stuff from the version you're merging in
>>>>>>>

---

酷，我不知道diff3的设置。那么这个文件会覆盖我工作目录中的文件吗？我的未提交更改会发生什么情况？IIRC，当您有未提交的更改时，不允许合并。您必须先隐藏第一个，然后合并。@jszakmeister严格来说这不是真的。如果未提交的更改与任何合并材质都不冲突，则会成功。我认为与未提交的更改冲突会导致合并失败……这似乎意味着我应该在执行
git merge
之前提交或隐藏更改。是吗？@mkasberg除非您确信所做的更改不会与合并冲突，否则隐藏或创建临时分支并在那里提交（这与隐藏的功能非常接近）可能是个好主意。