Question

以下情况：我和同事（或同事）在同一档案上工作。我对我的副本进行了一些更改，同事也对他们的副本进行了更改。他们推，当我拉 - 拉断，因为我的文件副本与头不同。即使我没有改变任何涉及同事变化的事情（例如，我改变了函数A（）和函数B（）中的同事）。

所以在这些情况下，我将更改保存在其他地方，用HEAD Revision替换文件，然后我成功拉动，然后应用我的更改。我见过的另一种方法是使用Merge Tool标签中的Team，但它仍然是手动合并每个更改的缓慢过程。

我的问题是，是否有办法避免这些冲突或何时发生冲突 - 自动合并更改？

Answer 1

合并地狱的一个过程可能是多个空格/制表符/换行符。请考虑以下示例：您的一位同事使用编辑器，用空格替换所有选项卡，并使用编辑器，用一个选项卡替换所有空格。在这种情况下，您将获得大量的合并冲突。

此问题的解决方案是在合并时使用-Xignore-all-space选项：

git merge -Xignore-all-space
git rebase -Xignore-all-space
git pull -Xignore-all-space

可能不会立即明显的小变化（感谢@rbatt）：

空格（可以使用-Xignore-all-space修复）
行结尾（请参阅core.autocrlf，core.safecrlf和core.eol配置属性）
可执行权限（chmod a+x ....）
符号链接与文件副本（ln -s ...）

Answer 2

Git无法决定自动合并是否会破坏代码的可编译性或更糟糕的语义。

示例：

你有一个像这样的源文件：

class A {
    //some Methods
}

如果添加方法：

class A {
    methodA() {...}
    //some Methods
}

并且你的coleague添加了一种方法：

class A {
    //some Methods
    methodA() {...}
}

你最终会在这样的文件中（在自动合并之后），由于我们现在有两个同名的方法，所以无法编译。

class A {
     methodA() {...}
    //some Methods
    methodA() {...}
}

这就是为什么总是一个人应该验证合并的原因。使用mergetool是个不错的主意。

Answer 3

Git将修改保存为通用补丁。由于其他人的工作可能会在受到修补程序影响的行之前添加或减少行，因此在合并或重新定位时，Git不能依赖行号。相反，Git会尝试确定更改的上下文，这意味着它会搜索您已更改的原始行（即使其位置已更改），并检查前导和尾随3上下文行保持不变。如果其他人更改了您已更改的相同功能，则没有安全方式自动合并这两个更改，在大多数情况下，人工干预是个好主意。

如果您遇到合并冲突的问题，只修改函数A（）并且同事修改函数B（），请尝试使用以下参数：

git pull -Xpatience

拉断时合并更改

3 个答案: