Git是如何解决合并问题的? [英] How does Git solve the merging problem?

问题描述

SVN 使分支变得非常便宜，从而使分支变得更加容易，但合并仍然是 SVN 中的一个真正问题 - Git 应该可以解决这个问题.

SVN made branching much easier by making branches really cheap, but merges remain a real problem in SVN - one that Git supposedly solves.

Git 是否实现了这一点，以及如何实现的?

Does Git achieve this, and how?

(免责声明:我所知道的关于 Git 的一切都是基于 Linus 的讲座——这里是 git noob)

(disclaimer: All I know about Git is based on the Linus lecture - total git noob here)

推荐答案

Git 不会防止合并中的冲突，但即使它们不共享任何父祖先，也可以协调历史记录.
(通过移植文件(.git/info/grafts)，这是一个列表，每行一个，提交后跟其父项，您可以为协调"目的进行修改.)
那里非常强大.

Git will not prevent conflict in merges but can reconcile history even when they do not share any parent ancestor.
(through The grafts file (.git/info/grafts), which is a list, one per line, of a commit followed by its parents, that you can modify for that "reconciliation" purpose.)
So pretty powerful right there.

但要真正了解合并是如何思考的"，您可以从 Linus 本人开始，并意识到这个问题与算法"无关:

But to really have a glimpse on "how merges have been thought through", you can start by turning to Linus himself, and realize this issue is not so much about "algorithm":

Linus:我个人，我想要一些非常可重复且不聪明的东西.我理解的或告诉我它做不到.
坦率地说，在不考虑所有其他文件的历史的情况下合并单个文件的历史让我感到呃".

Linus: Me personally, I want to have something that is very repeatable and non-clever. Something I understand or tells me that it can't do it.
And quite frankly, merging single-file history without taking all the other files' history into account makes me go "ugh".

合并的重要部分不是它如何处理冲突(如果它们很有趣，无论如何都需要由人类验证)，而是它应该将历史正确融合在一起，以便您有一个为未来合并提供新的坚实基础.

换句话说，重要的部分是微不足道的部分:父母的命名，并跟踪他们的关系.不是冲突.

In other words, the important part is the trivial part: the naming of the parents, and keeping track of their relationship. Not the clashes.

看起来 99% 的 SCM 人员似乎认为解决方案是在内容合并方面更加聪明.这完全没有抓住重点.

And it looks like 99% of SCM people seem to think that the solution to that is to be more clever about content merges. Which misses the point entirely.

<小时>

Wincent Colaiuta 补充说(强调我的):

---

So Wincent Colaiuta adds (emphasis mine):

不需要花哨的元数据、重命名跟踪等.
您唯一需要存储的是每次更改前后树的状态.

There is no need for fancy metadata, rename tracking and so forth.
The only thing you need to store is the state of the tree before and after each change.

哪些文件被重命名了?抄袭了哪些?删除了哪些?添加了哪些行?删除了哪些?哪些行在其中进行了更改?哪些文本块从一个文件复制到另一个文件?
您不必关心这些问题中的任何一个，当然也不必保留特殊的跟踪数据来帮助您回答这些问题:对树的所有更改(添加、删除、重命名、编辑等)) 在树的两个状态之间的增量中隐式编码；您只需跟踪什么是内容.

What files were renamed? Which ones were copied? Which ones were deleted? What lines were added? Which ones were removed? Which lines had changes made inside them? Which slabs of text were copied from one file to another?
You shouldn't have to care about any of these questions and you certainly shouldn't have to keep special tracking data in order to help you answer them: all the changes to the tree (additions, deletes, renames, edits etc) are implicitly encoded in the delta between the two states of the tree; you just track what is the content.

绝对可以(并且应该)推断出一切.

Git 打破常规，因为它考虑的是内容，而不是文件.
它不跟踪重命名，它跟踪内容.它是在整个树级别这样做的.
这与大多数版本控制系统完全不同.
尝试存储每个文件的历史记录并不费心；而是在树级别存储历史记录.
当您执行差异时，您是在比较两棵树，而不是两个文件.

Git breaks the mould because it thinks about content, not files.
It doesn't track renames, it tracks content. And it does so at a whole-tree level.
This is a radical departure from most version control systems.
It doesn't bother trying to store per-file histories; it instead stores the history at the tree level.
When you perform a diff you are comparing two trees, not two files.

另一个从根本上明智的设计决策是 Git 如何合并.
合并算法很聪明，但不会太聪明.明确的决定是自动做出的，但如果有疑问，则由用户来决定.
这是它应该的方式.您不希望机器为您做出这些决定.你永远不会想要它.
这是 Git 合并方法的基本见解:虽然其他所有版本控制系统都在努力变得更聪明，但 Git 很高兴地自称是愚蠢的内容管理器"，而且这样做更好.

The other fundamentally smart design decision is how Git does merges.
The merging algorithms are smart but they don't try to be too smart. Unambiguous decisions are made automatically, but when there's doubt it's up to the user to decide.
This is the way it should be. You don't want a machine making those decisions for you. You never will want it.
That's the fundamental insight in the Git approach to merging: while every other version control system is trying to get smarter, Git is happily self-described as the "stupid content manager", and it's better for it.

这篇关于Git是如何解决合并问题的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！