我的git项目让自己陷入了困境。（由于情况的原因）我们被迫将团队分为两个方面，一方负责大规模的升级/大修任务，另一方在我们上一个版本（分支机构也在这里分离）的基础上进行功能/错误修复
问题是，那是六个月前的事了。现在，功能团队已经完成了，我面临着将这两个分支合并为一个单一的、有凝聚力的状态的艰巨任务，这两个部门各包含六个月的工作。
不用说，有冲突。。。很多。具体来说，大约有400人。我能够通过重新定基而不是简单地合并来最大限度地减少混乱，这已经帮了我很多忙，尤其是当一个分支的修改文件被移动到另一个分支中的其他位置时。有很多这样的。
现在，虽然在大多数情况下，冲突本身并不是特别难以解决，但我无法摆脱这样一种感觉，即这不应该是任何一个开发人员单独承担的工作。
Git在这方面似乎不像往常那样乐于助人。因为理想的git工作流希望冲突保持较小并得到及时处理，所以似乎没有办法与团队其他成员共享合并工作。
那本来是很理想的。能够提交文件，而不必剥离它们的冲突状态。这样，其他开发人员可以查看正在进行的合并分支，并帮助消除双方的冲突，每个开发人员都会处理他们处理过的、最了解的文件。
但这似乎不可能。。。没有我能找到的那么远。
因此产生了这个问题。有人知道是否有一种方法可以在不暂存冲突文件的情况下提交冲突文件（从而将其标记为技术上已解决，使其以后很难找到）？
我希望能够查看一个有冲突的分支，查看那里的冲突，并在有人遇到麻烦时提供帮助，或者在这种情况下，寻求开发团队的帮助，他们现在只是坐在那里等待我尽我所能解决冲突，而无需大量上下文信息，这样，他们以后就可以进入并依靠合并提交消息中的冲突注释来尝试找出他们的工作可能被覆盖的位置。
和往常一样，非常感谢您的任何想法/想法/想法。任何事情都会有所帮助，如果至少能缓解不得不处理400个文件冲突的沮丧情绪的话。
干杯
好吧，至少作为后续行动，我能够在这里独自解决所有冲突。。。花了几个小时，但还是完成了。
然后，在我遇到了（意料之中的）一连串编译错误之后，我用diff工具检查了项目中的所有代码文件（与签出到某个源分支的另一个repo进行比较），并纠正了rebase操作（以及随后的冲突解决马拉松）失败的任何问题。
这一直持续到凌晨，但我设法以一个编译了的项目结束了这一天
今天，我正在修改项目资产文件及其在项目中的链接。这更简单，游戏看起来又像正常的自己，所以绝望的程度会相应下降。
尽管如此，如果有人知道一种分享重大冲突行动的方法（一些在不转移冲突状态的情况下进行承诺的方法，或者可能是一种重新检索技术上解决但仍然存在冲突的文件的方法），如果这种情况在未来再次发生（令人不寒而栗），这将是最受欢迎的信息。
感谢您的回复！
干杯
您肯定可以提交被git标记为冲突的文件。我建议您创建一个新分支，并将当前的两个分支合并到该分支中。这样，当你和你的队友解决第三个merge分支的问题时，人们可以继续在当前分支上工作。
你注意到这是一个不止一个人的问题，这是对的。如果它是一个足够大的项目，您通常会有团队参与更改代码的某些部分，因此这些人将负责解决merge分支上代码的这些部分中的合并冲突。
一旦所有内容都被合并，您可以简单地将开发切换到merge分支，或者将其合并回您的master分支。