解决GIT文件中的部分冲突
我想讨论的场景是 我有一个合并存储库，它是共享存储库，开发人员将进入其中以解决合并冲突。
- 单个文件中存在 2 个或多个合并冲突。
- 每个冲突都必须由不同的用户解决。
- 每个开发人员都将 cd 放入此存储库以解决合并冲突。
- 假设 foo.c 有 3 个合并冲突，
- 一个用户解决了 foo.c 中的一个冲突，并保存在图形合并工具中。
现在，GIT 将其识别为“git add”，尽管文件的其他部分仍然存在冲突。然后，如果另一个开发人员执行“git mergetool foo.c”，它不会因冲突而弹出 foo.c。
有没有一个图形工具可以解决这个问题。 允许多个用户解决冲突并将其保存在同一文件中。
The scenario that i would like to discuss is
I have a merge repository which is shared repository where developers will cd into to resolve merge conflicts.
- there are 2 or more merge conflicts in a single file.
- each conflict has to be resolved different user.
- each developer cd into this repository to resolve merge conflict.
- let say foo.c has 3 merge conflicts
- one user resolves a single conflict in foo.c and does save in a graphical merge tool
Now GIT recognizes this as "git add" though there are still conflicts in other parts of the file. Then if another developer does "git mergetool foo.c" it doesnt pop up foo.c for conflicts.
Is there a graphical tool that resolves this issue.
Allows multiple users to resolve and save conflicts in the same file.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这种情况实际上没有意义......
首先，如果存在冲突，那么该冲突仅存在于一个合并提交上，而该合并提交尚不存在！ （它仍然在用户的计算机上，可能在索引中，但肯定不在他们的本地树中）。
其他用户根本不存在冲突，直到他们进行合并或变基。
假设您确实有三个用户执行完全相同的合并，无论出于何种原因，因此他们具有相同的冲突。
让我们进一步假设，正如您所建议的，他们每个人都有一个只有他们可以协调的冲突，那么他们应该每个人都根据最新版本的代码重新调整他们的工作，并协调过程中的任何冲突。
换句话说，您似乎描述的情况如下：（如果我错了，请纠正我）：
理想情况下，在这种情况下应该做的是，任何知道如何进行合并的开发人员都应该合并“不稳定”。也许他们会选择一次合并几个提交，而不是直接合并两个头，或者他们可能选择重新设置整个事情的基础 - 不管怎样，但只有一个开发人员需要这样做。
然后，其余的开发人员将能够使用合并提交。
This scenario doesn't really make sense...
Firstly, if there is a conflict, then that conflict only exists on the one merge commit, which doesn't exist yet! (It's still on the user's machine, possibly in the index, but certainly not even in their local tree).
The other users do not have a conflict at all, until they do a merge, or rebase.
Supposing you do have three users doing the exact same merge, for whatever the reason may be, and therefore they have the same conflicts.
Lets further suppose that they, as you suggest, each have a conflict that only they can reconcile, then they should each rebase their work on the latest version of the code, and reconcile any conflicts in the process.
In other words, the situation you seem to be describing is as follows: (Correct me if I'm wrong):
Ideally, what should be done in this situation, is that 'unstable' should be merged in by any developer who knows how to do the merge. Perhaps they will choose to merge it a few commits at a time, rather than directly merge the two heads, or perhaps they choose to rebase the whole thing - whatever, but only one developer needs to do this.
The remaining developers will then be able to use the merge commit.