时间戳

首页 > 解决方案 > 在应用 git 补丁过程中发生冲突是否正常？

git - 在应用 git 补丁过程中发生冲突是否正常？

问题描述

我有两个存储库，比如说main repoand copy repo，它们必须使用补丁进行同步。他们的master分支是同步的，我从main repo-branch devon应用补丁copy repo。在创建补丁并将其应用到之后copy repo，我将dev分支合并到masteronmain repo以保持它们同步。

我已经main repo使用以下方法创建了补丁文件：

git format-patch origin/master..origin/develop --stdout > ../patches/patch-001.patch

当我尝试将此补丁应用到copy repo使用时：

git am -3 --ignore-space-change patch-001.patch

我得到Patch failed at 0002 ...并且我必须解决补丁文件中几乎每个提交的冲突。

问题是在应用补丁期间发生冲突是否正常？我以前做过，但没有发生这样的问题。

解决如此多的冲突（大约 50 次提交）是一个非常困难且令人困惑的过程。我正在使用PyCharm本身来解决每个补丁失败的冲突，但仍然很难。有没有更简单的方法来做到这一点？

为什么会发生这些冲突？是因为我merges在这些提交之间有吗？

标签： gitformat-patchgit-am

解决方案

这既不是“正常”也不是“异常”。就是这样。如果您的白猫在耳尖上出现生长缓慢的皮肤癌，则可以通过简单的手术轻松将其切除。浅肤色猫耳朵上的皮肤癌“正常”吗？如果您的猫外出，这是不正常的：黑色素含量低的皮肤细胞上的紫外线会导致突变，有时会导致基底细胞癌。您可以将猫留在室内（无论如何，大多数家猫通常都建议这样做），但这并不能保证他不会在粉红色的耳尖或鼻子上患上皮肤癌。1

为什么会发生这些冲突？

当 Git 进行合并时，Git 会找到三个输入文件。index:当您应用补丁时，如果补丁中有一行，Git 可能会选择进行合并。2 该index行告诉 Git原始文件是什么，补丁适用于哪个文件。然后，Git 可以将补丁（此时仅适用于原始文件）应用到该原始文件以生成“他们的文件”。

Git 现在拥有用于任何合并的相同信息：原始文件、包含更改的文件版本以及包含更改的文件版本。Git 现在可以将您的更改与他们的更改进行比较，以查看它们是否重叠。

如果他们更改的内容与您更改的内容无关，Git 将能够组合这些更改。例如，假设他们在第 10 行修正了单词的拼写，而你没有。相反，假设您通过在文件顶部添加 40 行版权声明来解决缺少版权声明的问题。Git 将能够看到该行现在是第 50 行，而不是第 10 行，并且它应该应用他们的修复。Git 将应用他们的修复程序，一切都会好起来的。speelingspeeling

但是，如果您还修复了该speeling行和同一行上的其他单词，Git 不知道是接受您的修复还是他们的修复。所以 Git 现在抱怨这条线上的合并冲突。那是因为您的更改会影响其更改所影响的基本文件的同一行。Git 不知道要使用哪些。

这正常吗？如果你们都更改了相同文件的相同行。这完全取决于“您”更改了哪些行，以及“他们”更改了哪些行，这取决于您从哪个通用起始版本开始的文件。如果您在此过程中从其他人那里获得了这些更改，则不会：只要他们 在开始的版本中没有这些更改，那么“您的”更改（包括其他人的更改）及其更改重叠，你会得到一个冲突。

请注意，即使您的更改及其更改不完全重叠，您也会遇到冲突。例如，如果他们更改了第 5 行到第 8 行，而您更改了第 9 行，这些更改“触及边缘”（“邻接”，使用花哨的词），Git 也会称其为冲突。

1当我住在犹他州时，我有一只纯黑色的小猫，鼻子上得了某种癌症。因此，即使有大量的黑色素也不能保证不会出现这种情况，尽管它会有所帮助。不过，她的生活相当不错，达到了“高级小猫”的地位。她的姐姐在前一年死于肾功能衰竭，所以即使她通过了癌症切除手术，她也可能不会持续太久。不幸的是，鼻子手术比耳尖修剪要大得多。

2如果补丁缺少索引行，Git无法进行三向合并。但这只是意味着不适用的补丁失败，而不是尝试合并；您将需要该--reject标志，并且您必须手动编辑补丁结果。

推荐阅读