Visual Studio 2015 GIT是否使用三向合并? [英] Does Visual Studio 2015 GIT use 3-way merge?
问题描述
当我使用Visual Studio 2015的合并工具来解决冲突时，似乎它的性能比我在GIT的命令行中使用P4Merge时(性能几乎没有发现)要差.
When I use Visual Studio 2015's merge tool to fix conflicts, it seems like it is performing worse than when I use P4Merge with GIT's command line (which finds almost no conflicts at all).
这是因为工具本身吗?Visual Studio 2015的合并/差异工具是否为GIT提供三向合并?
Is this because of the tool itself? Does Visual Studio 2015's merge/diff tool provide 3-way merge for GIT?
推荐答案
TL; DR :在合并Git存储库和尝试解决冲突时，Visual Studio都会进行三向合并出现.目前尚不清楚为什么VS在解决该冲突时会不如P4Merge，但我不知道其他任何事情，我怀疑P4Merge关于
TL;DR: Visual Studio does three-way merges, both when merging your Git repository and when trying to resolve the conflicts that arise. It's not immediately clear why VS would be inferior to P4Merge while resolving that conflict, but without knowing anything else, I suspect that P4Merge is better about inconsistent line ending configurations.
合并过程分为两个阶段:首先，执行合并并生成一个合并的树，其中包括两个分支的新更改以及(可能)冲突，其次是冲突解决阶段.
There are two stages to the merge process: first, performing the merge and producing a combined tree that includes new changes from both branches and (possibly) conflicts, and second, a conflict resolution stage.
在Visual Studio中，第一阶段是常规git合并，这实际上是三向合并.找到合并基础"，这是两个分支中存在的最后一个提交.这是您的两个分支最后一次合并，或从另一个分支创建一个分支的时间.
In Visual Studio, the first stage is a regular git merge, which is indeed a three way merge. The "merge base" is found, which is the last commit that exists in both branches; this is the last time your two branches were merged, or the point at which one branch was created from the other.
然后通过确定每个分支中哪些文件已更改并将它们与公共祖先进行比较，在树级别执行三向合并.如果文件在 one 分支中已更改，则该分支的更改将包含在新树中.如果文件在两个分支中都已更改，那么我们需要在文件级别进行三路合并，这非常相似，并将每个分支中的文件与其各自的文件进行比较.共同祖先.现在，如果相对于共同祖先，文件的任何区域在一个分支中进行了更改，那么我们将在合并的文件中包含该更改的区域.但是，如果两个分支都更改了同一区域，则会产生冲突.
Then a three way merge is performed at the tree level by determining which files have changed in each branch, comparing them to the common ancestor. If a file has changed in one branch, then that branch's changes will be included in the new tree. If a file has changed in both branches, then we need to do a three way merge at the file level, which is very similar and compares the files in each branch to their common ancestor. Now, if any region of the file has changed in one branch, relative to the common ancestor, then we'll include that changed region in the merged file. But if both branches have changed the same region, then a conflict will be produced.
Git将在工作目录中生成一个带有冲突标记的文件，但它还将记录这两个文件及其共同祖先，以便您可以使用合并工具(如Visual Studio或P4Merge).
Git will produce a file in the working directory with conflict markers, but it will also record the two files and their common ancestor so that you can use a merge tool (like Visual Studio or P4Merge).
(请注意，当您使用Visual Studio执行合并时，它会使用 libgit2 库，尽管
(Note that when you perform a merge using Visual Studio, it uses the libgit2 library, though it produces the same results as Git itself.)
一旦发生合并冲突，合并工具可以获取这三个文件，并为您提供解决冲突的图形体验.通常，每个工具中的第一步都是尝试再次进行文件级合并，并创建一个新的结果"文件(通常显示在三个窗格的中间窗格中，并且两个分支在两侧，或在两个分支文件之下或之下的情况比较少见.
Once you have a merge conflict, your merge tool can take the three files and provide you a graphical experience to resolve the conflicts. Typically, the first step in each of these tools is to try to do the file-level merge again, and will create a new "result" file (often shown in the middle pane of three panes, with the two branches on either side, or less commonly above or below the two branch files).
此结果通常将包括未重叠的任何区域，这些区域会自动合并，并且UI通常会提示您解决无法自动合并的重叠区域.一般来说，我的经验是，这里没有多少差异，但可以肯定会有差异.特别是:
This result will typically include any regions that were not overlapping automatically merged in, and the UI will generally prompt you to resolve the overlapping regions that couldn't be automerged. Generally speaking, my experience is that there isn't a lot of difference here, but certainly there could be variations. In particular:
-
某些工具可能会更积极地将彼此接近的小冲突合并在一起，这可能会产生较少但较大的冲突，而这些冲突可能更易于解决-例如，如果您有多个冲突，最好将它们排成一个更大的冲突.
Some tools may be more aggressive about joining small conflicts that are near to each other together, which may give fewer but larger conflicts that may be easier to resolve - for example, if you had several conflicts that were one-line each it may be preferable to squash those into a single, larger conflict.
某些工具可能会进行编码转换，以便您可以正确合并一个文件，该文件在公共祖先中为UTF-8，在一个分支中为UTF-16，在另一个分支中为Latin1，并在一个文件中获得智能输出.这些编码中的一种(甚至完全不同).
Some tools may do encoding translations, so that you can correctly merge a file that was UTF-8 in the common ancestor, UTF-16 in one branch and Latin1 in the other branch and get an intelligent output in one of those encodings (or even a different one altogether).
某些工具可能会忽略空格更改.我有一种预感，那就是您可能会发现Visual Studio和P4Merge之间存在差异.众所周知，在Windows Git客户端的整个团队中都难以设置行结束配置.仅仅忽略行尾差异的合并工具会比没有合并的工具产生更好的体验.
Some tools may elide whitespace changes. I have a hunch that this might be where you're seeing differences between Visual Studio and P4Merge; line ending configuration is notoriously difficult to setup across an entire team in Windows Git clients. A merge tool that simply ignored line ending differences could produce a much nicer experience than one that did not.
您甚至可以使用能够理解文档结构的工具:例如，合并两个XML文件通常不会尝试理解XML的结构，而是
You could even use a tool that understood the structure of your document: for example, merging two XML files typically doesn't try to understand the structure of the XML, but you could use a tool that understood XML to avoid things like whitespace changes that don't actually matter to the meaning of the file.
这篇关于Visual Studio 2015 GIT是否使用三向合并?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
