在GIT中解决文件冲突的一部分

Question

我想讨论的场景是：我有一个合并仓库，这是一个共享仓库，开发人员会进入该仓库来解决合并冲突。

1. 单个文件中有2个或更多的合并冲突。
2. 每个冲突必须由不同的用户解决。
3. 每个开发人员都要进入这个仓库来解决合并冲突。
4. 假设foo.c有3个合并冲突。
5. 一个用户在图形化合并工具中解决了foo.c中的一个冲突，并保存了修改。

现在GIT将此视为“git add”，尽管文件的其他部分仍存在冲突。然后，如果另一个开发人员执行“git mergetool foo.c”，它不会弹出foo.c以解决冲突。

是否有一种图形化工具可以解决这个问题。 允许多个用户在同一个文件中解决和保存冲突。

- Senthil A Kumar

Answer 1

这种情况并没有什么意义...

首先，如果存在冲突，那么这个冲突只存在于一个合并提交中，而这个提交还不存在！（它仍然在用户的机器上，可能在索引中，但肯定不在他们的本地树中）。

其他用户根本没有冲突，直到他们进行合并或变基。

假设您确实有三个用户执行完全相同的合并操作，无论出于何种原因，因此他们有相同的冲突。

进一步假设，正如您所建议的那样，每个用户都有自己可以调和的冲突，那么他们应该将自己的工作变基到代码的最新版本，并在此过程中调和任何冲突。

换句话说，您似乎描述的情况如下：（如果我错了，请纠正我）：

1. 我们有三个开发人员，Charlie、John和Matt，他们都在主分支上工作，该分支位于提交aaaaaaa。
2. 他们还在一个“不稳定”的分支上工作，该分支位于提交bbbbbbbb，已经与“主”分支分叉。
3. 他们同时决定将“不稳定”的分支合并到“主”分支中。
4. 他们同时意识到他们有无法协调的提交。

理想情况下，在这种情况下应该由任何知道如何执行合并的开发人员将“不稳定”的分支合并。也许他们会选择一次合并几个提交，而不是直接合并两个头，或者他们选择重置整个内容 - 无论如何，只需要一个开发人员执行此操作。

The more frequently this is done, the easier the merge/rebase operation will be.

其余的开发人员将能够使用合并提交。

- Arafangion

---

这不是我想要的...需要更好的解释。 我试图合并两个裸仓库，而不是合并实际数据仓库中的分支。由于没有工作目录，因此无法合并2个裸仓库，所以我从1个裸仓库（A）创建了一个名为merge_A的克隆，并从2个裸仓库（B）拉取更改，因此在merge_A中发生合并冲突。现在假设foo.c有3行冲突，并且有3个开发人员必须进入merge_A并解决它。 - Senthil A Kumar

这三个开发人员为什么不能在自己的代码库中合并呢？为什么他们需要聚集在一个小屏幕周围，争夺键盘控制权呢？你所说的冲突很少只是一个文件，而是整个项目中各种类型的争夺！ - Arafangion

这个项目非常庞大，跨越多个国家，因此我将把这个项目作为共享存储库（660），以便每个开发人员都可以进入这个共享路径并进行更改。 - Senthil A Kumar

分布在不同国家？进入共享路径？这里有些混淆了。:(（这些不同的国家甚至与此对话没有任何关系！） - Arafangion