GIT 拉取和合并生成暂存文件和冲突答案

【问题标题】：GIT Pulling and merging generates Staged files and conflictsGIT 拉取和合并生成暂存文件和冲突
【发布时间】：2014-07-17 07:29:17
【问题描述】：

我们决定采用 GITFlow 工作流，并使用 Eclipse（带 EGit）来开发我们的软件。

每当有人提交并将其推送到远程存储库并且我进行后续拉取（或获取和合并）时，我都会收到更改并且遇到了 2 个问题：

其他开发人员更改的所有文件在我看来都是非暂存文件。对我来说这没有意义，因为我没有对文件做任何事情，他们应该自己更新。
我们经常遇到文件合并冲突，当我们查看时根本没有任何冲突，即它们没有任何区别，除了 Git 已将文件的内容复制并再次粘贴到文件上方。李>

有人可以解释一下，给我一些信息或可以澄清这些观点或我应该如何处理它们的东西吗？

【问题讨论】：

见stackoverflow.com/q/8227233/1700321 和stackoverflow.com/q/1510798/1700321。并使用命令行或 SourceTree 而不是 egit。 ;)

标签： eclipse git egit

【解决方案1】：

对于您的第一点，我刚刚在这里回答了同样的问题：https://stackoverflow.com/a/29463230/209288

Pull 应该进行一次提取和一次合并，这本身就是一次提交。因此，其他人的这些更改将应用于文件，暂存，然后自动提交。如果此自动合并提交出现问题（例如冲突），那么您将在解决冲突时看到其他人的更改处于暂存状态。

第二点——我也看到过“虚假”的冲突，多年后还没有对其中的一些得出结论！

有时它是空格：例如正在转换的制表符/空格或换行符。大多数 Git GUI 在差异窗格中都有一个“隐藏空格”选项，用于解决冲突的合并工具也是如此。因此，有时 Git 认为的冲突由外部合并工具更优雅地处理，因为您在其配置中放宽了空格规则。有时，当您关闭忽略空白选项时，看起来没有变化的是空白变化。

我得出的唯一另一个结论是，外部合并工具在合并方面可能比 Git 本身更好——或者至少遵循稍微不同的算法。因此当 git 向外部工具抛出冲突时，它可能能够解决它并显示没有冲突！

“除了Git将文件内容复制并粘贴到文件上方之外，它们没有任何区别。”

我不确定我是否完全理解，如果您说文件内容在其内部重复，那么您可能会看到冲突差异格式。如果行尾不同，这将复制整个文件。

如果你看到这个：

<<<<<<< HEAD
...entire file contents...
=======
...entire file contents...
>>>>>>> otherbranch

那么我几乎可以保证你的行尾已经改变了。

【讨论】：

【解决方案2】：

Aleksandr M 的消息澄清了很多事情：请参阅 stackoverflow.com/q/8227233/1700321 和 stackoverflow.com/q/1510798/1700321。并使用命令行或 SourceTree 代替 egit。 ;) – Aleksandr M 31 分钟前

我还警告您要两次验证您推送的内容：

我们经常遇到文件合并冲突，当我们查看时根本没有任何冲突，即它们没有任何区别，除了 Git 已经复制并再次粘贴文件的内容到文件上方.

即使一个文件没有被修改，他的二进制关联也可以，如果你push这两个，那么就会有冲突，因为它们没有相同的哈希码SHA1。

（具有相同SHA1哈希码的两个对象是相同的，用于识别文件，并且具有相同SHA1哈希码的两个对象永远不会重复）

【讨论】：

我不认为这是正确的。如果两个人在一个版本的子版本中修改/同一行/然后尝试将它们合并在一起，则会出现冲突。它们在 git 眼中是平等的，因此它无法选择保留哪个更改。拥有不同的哈希并不重要，您可以为相同的文件内容使用不同的哈希 - 例如您可以修改文件，提交它，然后将其修改回来并接收不同的哈希，但文件是相同的。那么如果你把它合并进去，你肯定不会发生冲突，因为没有区别。