问题标签 [merge-conflict-resolution]

我们三个人使用 git 在一个 Django 项目上工作。

我比其他 2 人有更多的经验，所以所有的变化都是在他们进入“大师”之前由我来完成的。

我们都在运行 Windows，并且我们不在基于磁盘的共享可以工作的地方，因此我们在 linux 机器上的个人帐户中都有单独的“来源”存储库。这些是我们相互分享更改的一种方式，也是我们存储库的“异地”备份。

另外两个人中的一个创建了一个分支，我们称之为 BugA，他们进行修复。然后他们将其从他们的工作机器推送到我们都可以访问的 linux 机器上，以便我可以查看更改并将它们合并到我帐户上的“主”中（这被认为是投入生产的代码副本）。

一旦他们完成了 BugA，他们将用一个新的分支开始 BugB。当我审查他们的工作时，我发现了一些问题（多余的代码，缺少注释等......）所以我对他们的代码进行了更改，对其进行测试并将其提交给 master。

然后他们将 BugB 的修复发送给我，我得到了与他们的更改发生的各种冲突。这些冲突发生在我在提交中更改的代码行上。

当他们试图与我合并时，他们也会报告他们的冲突。

在写这篇文章的时候，我想我开始明白可能出了什么问题。我正在将他们的代码合并到我的主人中，进行编辑和提交。我真的需要在我的仓库中对他们的分支进行更改，将其推回以供他们合并，然后将它们合并到我的 master 中。

我不确定的是该怎么做。一旦他们与我的仓库中的分支合并，那么他们必须与我的主人合并吗？2 合并而不是 1？

由于我们在 linux 机器上有一个外部托管的 repo 的方式，这意味着两次推送，两次合并等......

这真的是它应该如何工作的吗？

我有两个本地分支机构master和dev. 两个分支都包含三个文件夹：

我只想保留projectBeta并删除project，project_v1然后重命名projectBeta为project. 所以这就是我在两个分支上分别做的事情，我一直在做。在我尝试将dev分支合并到 master 之前，一切看起来都很好，我得到了一堆这样的错误：

所以看起来 Git 在不同的分支中以不同的方式跟踪重命名。

如果我做 a git status，我会得到

我不明白的第一件事是，当合并报告说它被我们和他们重命名和删除时，为什么状态只是说它是“我们添加的”？

其次，我想使用test.c的dev分支版本（它们），但是现在当我尝试

我明白了

...所以我不知道如何确保合并将使用 dev 分支中的内容？

最后，有没有一种最佳实践方法可以避免将来出现这样的混乱局面？基本上，在内容尚未准备好首先合并的分支中独立更改文件夹结构......

在 git 中拉（合并）文件末尾的换行符差异时，我经常遇到冲突。

冲突看起来像这样：

更差; 在我手动解决文件并添加冲突文件之后，似乎没有任何东西可以提交（相对于文件的结尾），所以当我再次拉动时，我得到了完全相同的冲突。有什么解决办法吗？

我的困惑源于从此处获取的以下声明：

当拉取相互冲突的补丁（例如，更改文件的相同部分）时，Darcs 会检测到冲突并将其标记在存储库内容中。然后它让用户解决问题。

这似乎与我所看到的不一致，因此我使用 darcs 2.5.2 创建了以下工作流程：

1. 创建回购 foo；
2. 在 foo 中创建一个非空文件并记录下来；
3. 将 foo 克隆到 bar；
4. 删除foo中的文件并记录；
5. 在bar中的文件中添加另一行并记录它；
6. 从 foo 拉入 bar，获取冲突通知；

采取这些步骤后，我darcs whatsnew在 bar 中运行，并显示了两个“补丁原语”：

1. 删除所有“foo 中的非空文件”的大块头，但没有提及在 bar 中添加和记录的行；
2. 删除文件的 rmfile。

我的问题是：为什么没有提及添加并记录在栏中的行？

如果我darcs revert在 bar 中运行，那么一切都是有道理的：我看到“非空文件”受到两个冲突补丁的影响，根据从这里获取的语句：

命令 darcs revert 将删除冲突标记并恢复到冲突补丁之前的状态。

但是，如果我运行darcs mark-conflicts，我会回到与拉动后相同的状态，使用上面提到的两个“补丁原语”，并且没有提及添加并记录在 bar.xml 中的行。

供参考/复制这里是我从命令行的完整工作流程：

我仍然没有确定的方法来重现它，但如果这是一些众所周知的问题，我还是会问它。发生的事情是 git 经常会产生这样的冲突：

因此，git 并没有注意到我只是添加了一段新代码，而是认为我修改了整行代码。这有时会发生在文件的中间，但最常见的是 - 在文件的末尾。我的猜测是它可能与行尾字符有关，但我还需要运行测试来确认这一点。有没有人有同样的问题，如果是，你如何解决它？

给定一个冲突的文件foo.txt，如何告诉git diff显示文件的基本版本和文件的“他们的”版本之间的变化？

git show :1:foo.txt我可以通过or查看每个版本git show:3:foo.txt- 有没有一种简单的方法来比较这两个版本？

我最近开始使用 Bzr 共享存储库来管理我的项目。我通过从一个独立的存储库分支来得出这一点，到目前为止我一直在进行增量提交。这个新的共享存储库有一个“/trunk, /branches”布局：

因此，我将此存储库的主干中的一些更改合并到主线中，但是当我后来尝试从主干推送一些进一步的更改时，我收到一个错误，指出两个分支已经分歧。我已将合并提交到主线中，因此出现了分歧。但是，鉴于必须提交任何合并，如何避免这种情况呢？还是我严重误解了事情？

为了解决这个冲突，我从主线 BACK 合并到共享主干分支。我怀疑这是一个错误，因为我现在有 /xxxx_shared/trunk 的修订历史，如下所示：

所以上面的 71.1.1 已经从主线合并了，是指从 /projects/xxxx_shared/trunk (shared repo) 合并到主线。

我希望这一切都清楚。但是如何解决这个问题以恢复线性发展呢？什么是 Bzr 的保守“最佳实践”，以避免将来发生这种事情？我仍然有原始独立存储库的未修改副本，因此如果需要，我可以随时返回并重新开始。

您知道 Sync Framework 中的合并冲突解决策略是如何工作的吗？这里的文档：http: //msdn.microsoft.com/en-us/magazine/dd569762.aspx说框架默认支持 Merge。但是，该框架跟踪的是行级别的更改，而不是列级别的更改，那么合并究竟是如何工作的呢？

我对 Mercurial 和 Python 感到沮丧，因为它让简单的事情变得困难。我有一个微不足道的冲突，由于 Mercurial 没有给出任何建议，我什至不知道如何解决这个微不足道的文件冲突：

冲突是微不足道的，但如果我无法解决这个问题，我也无法解决任何复杂的问题。我可以将文件编辑为我想要的方式并从任何地方再次提交吗？我应该跑hg merge吗？为什么 Mercurial 甚至不能让我选择要保留的版本？为什么不深入研究 1000 个写得很糟糕的联机帮助页就几乎不可能完成一些微不足道的事情？

We've done something bad.

We ran git stash save during a merge conflict, and now we can't restore our work.

Things we've tried:

And:

Please help!