问题标签 [merge-conflict-resolution]

我有一个使用 git 的项目。当我收到 repo 时，它有一些未提交的更改。我承诺了这些，并开始自己制作。

我收到了另一位开发人员的工作，该开发人员将他们的更改和原始未提交的更改提交到单个提交中。

现在我在不同的文件夹中有两个 git 存储库，我想知道如何将我的更改合并到开发人员更改中，并尽可能减少冲突。

我们的项目用于svn管理源代码版本。我们有一个问题，当一个xib被2人修改时，合并后几乎会发生冲突。我用vim打开了confilct文件，信息不可读，不知道如何解决合并冲突。

有没有人遇到过这个问题？如何解决？

提前致谢。

这可能是一个幼稚的 git 问题，但它是：

在进行拉取请求之前，我通常从上游的最新提交创建一个新分支，并从我的开发分支中挑选重要的提交。然后从我的新分支向远程存储库发出拉取请求。

但是我讨厌合并冲突（尽管 git mergetool 在它们发生时有很大帮助）。我怀疑其中一些冲突是由樱桃挑选的顺序引起的。我通常会从最旧到最新的提交中挑选一组提交。这是正确的方法吗。还是提交顺序对git无关紧要？

是否有任何其他技巧可以最大限度地减少樱桃采摘期间的合并冲突？

我想知道大型 repo（例如 Linux 内核）的维护者如何合并“重要”分支，例如 next pu maint 等。一个人如何知道如何解决合并冲突？我假设这些重要的分支可能会因源代码树不同部分的许多不同人的许多提交而分道扬镳。合并两个这样的分支必须由一个人完成，因此您不能将冲突拆分为特定冲突领域的专家来解决。

我做了一个 git pull ，发现我的一个文件需要合并。

我现在真的不想合并那个文件——我还有另一个分支需要处理，稍后我会回到这个分支来解决合并问题。

对我来说“撤消”这种拉动的最佳行动方案是什么？或者在我准备好处理它之前，我如何才能推迟这个合并？我需要做什么才能更改分支，然后在我的代码中返回到这个未合并状态？

Lets assume that we have one development branch 'A', and two sub branches 'B1' and 'B2', (both taken from A). Lets say that you run a format code command (in our case ReSharper's cleanup code) on the entire project in B1 and B2.

Now, when we try to merge B2 into B1, Git will report conflicts on all files in the project (quite a large number in our case). When looking closer at each conflict, it seems like Git thinks theres a conflict even though the exact same change was made in both B1 and B2(?)

Is there a way, custom driver/git attribute etc that will make a Git merge operation not report a conflict if the files in B1 and B2 are exactly the same?

Maybe I've got it wrong, maybe it is a whitespace/line ending issue (eg different line endings in B1 and B2) in which case I can find the solution here on stack overflow.

我在 iOS 应用程序的版本控制中面临两个分支的复杂合并。在我识别并选择了 中的冲突行之后project.pbxproj，Xcode 将不会加载该文件。运行它plutil显示了这一点：

CFPropertyListCreateFromXMLData()：旧式 plist 解析器：字典中缺少分号。

我已经恢复并尝试了几次合并（小心地），每次都得到相同的结果，尽管我看不到我在哪里引入了格式问题。

有没有一种工具可以用来至少找出错误所在的行或对象，以便找到我正在犯的错误？

我正在考虑向其用户提供对 SaaS 应用程序使用的资源的某种 Git 访问权限的想法。这将允许用户通过 Git 界面以及应用程序的本地基于 Web 的界面编辑和推送内容。我主要关心的是当用户编辑基于 Web 的界面中的内容时如何协调合并冲突（我不太关心来自 Git 界面的合并冲突，因为 Git 和他们的 Git 客户端应该处理这个问题）。这与 GitHub 允许基于 Git 和基于 Web 的访问其 Wiki 的方式非常相似，我很好奇他们如何处理这种情况，作为其他人在提供基于 Web 和基于 Git 的访问时遵循的模式内容。

如果用户通过 Web 界面编辑 GitHub 上的 Wiki 页面，而另一个用户在完成之前将更改推送到 Wiki 存储库分支，那么当他们保存更改时会发生什么？它是使用“最后一个获胜”还是“抱歉，在新版本上重做所有更改”？

我发现了一篇相关的 SO 帖子，它总体上讨论了这个问题，但我很好奇 GitHub 是如何专门处理它的，因为它得到了 Git 的支持，而 Git 已经内置了一些合并功能。

我合并了两个分支，但最终的文件是这样的：

我不知道它代表什么，他们是否有任何 GUI 工具可以以更易于阅读的格式显示数据？谢谢。

我有一个长期存在的功能开发分支，我们称之为 dev-foo。问题是，当我尝试将它合并到 release-1 中时，我会遇到各种可怕的树冲突和源冲突，这些都没有任何意义。我已经将它们重新集成到一个新的基于主干的分支中，以及其他想要集成在一起的功能。我尝试与此集成分支进行的每次合并都同样存在可怕的冲突。我能做些什么？